From owner-ipng@sunroof.eng.sun.com Fri Feb 1 02:52:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11AqX2Q022850 for ; Fri, 1 Feb 2002 02:52:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11AqXQK022849 for ipng-dist; Fri, 1 Feb 2002 02:52:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11AqU2Q022842; Fri, 1 Feb 2002 02:52:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08326; Fri, 1 Feb 2002 02:52:45 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20135; Fri, 1 Feb 2002 03:52:42 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 575C5A; Fri, 1 Feb 2002 12:53:54 +0200 (EET) Message-ID: <3C5A7353.10705@nomadiclab.com> Date: Fri, 01 Feb 2002 12:52:03 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com Cc: "Charles E. Perkins" Subject: The semantics of the Routing Header? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, Related to the debate on the mobile-ip list on whether MIPv6 should use Routing Header or some other mechanism to carry the home address to a mobile node that is away from home, I'd like to solicit for well grounded opinions on the intended semantics of the Routing Header. To properly understand what I am really asking about we must first make a distinction between two logical entities, endpoints and locations. In the current Internet architecture, both endpoints and locations are identified with a single mechanism, i.e. with IP addresses. However, they are conceptually different, as very well pointed out by Noel Chiappa in http://users.exis.net/~jnc/tech/endpoints.txt In essense, a communication endpoint is an active entity engadged in the communications, i.e. a party who consumes messages and generates new ones. A location, on the other hand, is a topological "place" within the routing fabric. Now, my question is fairly simple: Is the meaning of the routing header to allow a packet to be sent through a number of communicating hosts (end-points) or via a specific path, identified by a set of locations? Or is it both? One way of pondering the question is to imagine that the endpoints and locations had different name spaces. For example, you could imagine that each host has a flat name tag (HIT in HIP terminology), and the locations are named according to the routing hierarchy as today. Under such an architecture, would the routing header contain addresses or these new name tags, or could it contain a mixture of both? The reason why I am asking this is the scenario, which Charlie Perkins has offered, where a packet is source routed through a Mobile Node that is away from home. According to his argumentation, in such case the routing header should have a route looking like .... - Care-of-Address - Home Address - .... where the Care-of-Address is the current location of the mobile node, and the Home Address is more like the end-point identifier of the mobile node. I am having hard time in clearly crasping the intended semantic meaning of this construction. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 04:00:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C082Q023168 for ; Fri, 1 Feb 2002 04:00:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11C08Jn023167 for ipng-dist; Fri, 1 Feb 2002 04:00:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C042Q023160 for ; Fri, 1 Feb 2002 04:00:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05703 for ; Fri, 1 Feb 2002 04:00:18 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03085 for ; Fri, 1 Feb 2002 05:00:17 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g11C0Ck17618 for ; Fri, 1 Feb 2002 13:00:12 +0100 (MET) To: ipng@sunroof.eng.sun.com Subject: RFC 3056 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 1 Feb 2002 13:00:10 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/01/2002 13:00:12, Serialize complete at 02/01/2002 13:00:12 Content-Type: multipart/alternative; boundary="=_alternative 0041EEDAC1256B53_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0041EEDAC1256B53_= Content-Type: text/plain; charset="us-ascii" Hello, When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not get answered. Consider the router that originates the IPv4 tunnel. Which IP address should this router use as the source IP addres in its IPv4 encapsulation header: * Should this address be the router id of this router? Or * Should the source IPv4 address be derived from the source IPv6 address Or ...? Thanks for any help you can provide, Francis. --=_alternative 0041EEDAC1256B53_= Content-Type: text/html; charset="us-ascii"
Hello,

When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not get answered. Consider the router that originates the IPv4 tunnel. Which IP address should this router use as the source IP addres in its IPv4 encapsulation header:

* Should this address be the router id of this router?
Or
* Should the source IPv4 address be derived from the source IPv6 address
Or
...?

Thanks for any help you can provide,

        Francis. --=_alternative 0041EEDAC1256B53_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 04:04:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C4e2Q023240 for ; Fri, 1 Feb 2002 04:04:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11C4dHH023239 for ipng-dist; Fri, 1 Feb 2002 04:04:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C4a2Q023232 for ; Fri, 1 Feb 2002 04:04:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23636 for ; Fri, 1 Feb 2002 04:04:50 -0800 (PST) Received: from sluis.cs.vu.nl (sluis.cs.vu.nl [192.31.231.174]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05534 for ; Fri, 1 Feb 2002 05:04:50 -0700 (MST) Received: from centaur.cs.vu.nl by sluis.cs.vu.nl with esmtp (Smail #71) id m16WcQy-000OY1C; Fri, 1 Feb 2002 13:04 +0100 Received: from centaur.cs.vu.nl (localhost) by centaur.cs.vu.nl with esmtp (Smail #71) id m16WcQy-0014QLC; Fri, 1 Feb 2002 13:04 +0100 Message-Id: To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill- py.sacramento.ca.us> <22735.1012464548@brandenburg.cs.mu.OZ.AU> <38720000.1012506916@localhost> In-reply-to: Your message of "Thu, 31 Jan 2002 20:55:16 +0100 ." <38720000.1012506916@localhost> Date: Fri, 01 Feb 2002 13:04:48 +0100 From: Philip Homburg Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your letter dated Thu, 31 Jan 2002 20:55:16 +0100 you wrote: >--On Thursday, January 31, 2002 03:09:08 PM +0700 Robert Elz > wrote: >> I probably wouldn't either, though we don't want to totally forget >> allocation efficiency - the way we make sure that IPv6 never runs >> out is to always make sure we justify every allocation (which >> doesn't mean organisations need to justify their need for a /48 - > >> but I'd certainly be making any organisation asking for a 2nd one >> (in the same aggregatable block, > >If this will happen, which organisation would this be? Compared with >current IPv4 /48 with the 16 bits for SLA is similar to a IPv4 Class >A network. What happens if an organization has a modem bank for dail-in? Do you hand out /64s or something larger? Suppose that you want to give each 'modem user' a fixed prefix, how soon do you run out of prefixes? Philip Homburg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 05:55:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Dtn2Q023486 for ; Fri, 1 Feb 2002 05:55:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11DtmrD023485 for ipng-dist; Fri, 1 Feb 2002 05:55:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Dtj2Q023478; Fri, 1 Feb 2002 05:55:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16991; Fri, 1 Feb 2002 05:56:00 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08426; Fri, 1 Feb 2002 06:55:59 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA12534; Fri, 1 Feb 2002 14:55:51 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62760 from ; Fri, 1 Feb 2002 14:55:45 +0100 Message-Id: <3C5A9E61.9CD8272E@hursley.ibm.com> Date: Fri, 01 Feb 2002 14:55:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Nikander Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com, "Charles E. Perkins" Subject: Re: The semantics of the Routing Header? References: <3C5A7353.10705@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's fairly clear that architecturally, IPv4 and IPv6 are at exactly the same place on this: the notions of identifier and locator are 100% overlaid on each other. So in practical terms - what can we do, and standardize, *today* - we simply can't make the distinction. The IRTF NameSpace research group has been working inconclusively on the architectural issue for a couple of years. See http://www.ietf.org/internet-drafts/draft-irtf-nsrg-report-01.txt for a snapshot. imho it is best to disregard the philosophical side if you want to make progress immediately. What's the practical issue with embedding the home address in such a routing header? Brian Pekka Nikander wrote: > > Hello all, > > Related to the debate on the mobile-ip list on whether > MIPv6 should use Routing Header or some other mechanism > to carry the home address to a mobile node that is > away from home, I'd like to solicit for well grounded > opinions on the intended semantics of the Routing Header. > > To properly understand what I am really asking about we > must first make a distinction between two logical > entities, endpoints and locations. In the current > Internet architecture, both endpoints and locations are > identified with a single mechanism, i.e. with IP addresses. > However, they are conceptually different, as very well > pointed out by Noel Chiappa in > http://users.exis.net/~jnc/tech/endpoints.txt > In essense, a communication endpoint is an active > entity engadged in the communications, i.e. a party > who consumes messages and generates new ones. A location, > on the other hand, is a topological "place" within the > routing fabric. > > Now, my question is fairly simple: Is the meaning of > the routing header to allow a packet to be sent through > a number of communicating hosts (end-points) or via a > specific path, identified by a set of locations? Or > is it both? > > One way of pondering the question is to imagine that the > endpoints and locations had different name spaces. For > example, you could imagine that each host has a flat > name tag (HIT in HIP terminology), and the locations > are named according to the routing hierarchy as today. > Under such an architecture, would the routing header > contain addresses or these new name tags, or could > it contain a mixture of both? > > The reason why I am asking this is the scenario, which > Charlie Perkins has offered, where a packet is source > routed through a Mobile Node that is away from home. > According to his argumentation, in such case the > routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > > where the Care-of-Address is the current location of > the mobile node, and the Home Address is more like > the end-point identifier of the mobile node. I am > having hard time in clearly crasping the intended > semantic meaning of this construction. > > --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 06:34:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11EYJ2Q023565 for ; Fri, 1 Feb 2002 06:34:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11EYJ57023564 for ipng-dist; Fri, 1 Feb 2002 06:34:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11EYF2Q023557 for ; Fri, 1 Feb 2002 06:34:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22292 for ; Fri, 1 Feb 2002 06:34:31 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29567 for ; Fri, 1 Feb 2002 07:34:29 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g11EYH827137; Fri, 1 Feb 2002 16:34:17 +0200 Date: Fri, 1 Feb 2002 16:34:17 +0200 (EET) From: Pekka Savola To: francis.arts@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002 francis.arts@alcatel.be wrote: > When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not > get answered. Consider the router that originates the IPv4 tunnel. Which > IP address should this router use as the source IP addres in its IPv4 > encapsulation header: > > * Should this address be the router id of this router? > Or If router-id is V4ADDR in 2002:V4ADDR. > * Should the source IPv4 address be derived from the source IPv6 address > Or > ...? Yes. See RFC3056 Chapter 3: IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of 41, the same as has been assigned [MECH] for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header contains the Destination and Source IPv4 addresses. One or both of these will be identical to the V4ADDR field of an IPv6 prefix formed as specified above (see section 5 for more details). The IPv4 packet body contains the IPv6 header and payload. (btw, this is ngtrans, rather than ipng, material) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 08:02:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11G2Z2Q023709 for ; Fri, 1 Feb 2002 08:02:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11G2YtL023708 for ipng-dist; Fri, 1 Feb 2002 08:02:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11G2V2Q023701 for ; Fri, 1 Feb 2002 08:02:32 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18917 for ; Fri, 1 Feb 2002 08:02:46 -0800 (PST) Received: from envy2.nxs.se (envy.nxs.se [212.247.200.182]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19654 for ; Fri, 1 Feb 2002 08:02:44 -0800 (PST) Received: by envy2.nxs.se (Postfix, from userid 1000) id CA171810AF; Fri, 1 Feb 2002 17:02:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by envy2.nxs.se (Postfix) with ESMTP id C9812810AD; Fri, 1 Feb 2002 17:02:42 +0100 (CET) Date: Fri, 1 Feb 2002 17:02:42 +0100 (CET) From: Tomas Lund To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: <2651.1012549451@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Robert Elz wrote: > | 3. Is it ok to use longer than a /64 for links ? > > That is, the suggestion isn't to pressure people to use /126 or something > (as your #2 would do), nor to tell people that it isn't OK to use a /64 /127 seems alot better? Why waste 50%? //tlund -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 08:33:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11GXH2Q023899 for ; Fri, 1 Feb 2002 08:33:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11GXGqh023898 for ipng-dist; Fri, 1 Feb 2002 08:33:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11GXD2Q023891 for ; Fri, 1 Feb 2002 08:33:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26146 for ; Fri, 1 Feb 2002 08:33:27 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15530 for ; Fri, 1 Feb 2002 09:33:26 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 08:33:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGrGQXXG35NdJzxSgSMqqLzqufscgAJAjjQ From: "Michel Py" To: "Philip Homburg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g11GXD2Q023892 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre and Philip, > I find it almost impossible to work out where /80 comes from (unless > you mean to find a need to do so, in which case, then yes, I'd find > that pretty difficult too, though I prefer more often to have > constant 0 bits in higher order positions than lower ones, so I'd > tend to make the mask longer, and put 0's in the subnet section > rather than shorter with 0's in the host part - but that's just > aesthetics). But if there's something supposedly magic about the last > 48 bits (48 now is 100% irrelevant to autoconf, so it cannot be > that) it has escaped me. What I had in mind was that if someone felt like re-inventing the wheel and create a new autoconf, it would be extremely difficult not to use the 48-bit MAC address (nobody would buy having ARP for IPv6), therefore going beyong /80 would be very difficult. > For giving advice to the population at large, I'd probably suggest using > /64 for almost all nets, to lower the chances of running into limits in > the technology that shouldn't be there (but bugs exist everywhere). Concur. > Philip Homburg wrote: > What happens if an organization has a modem bank for dail-in? Do you > hand out /64s or something larger? Suppose that you want to give each > 'modem user' a fixed prefix, how soon do you run out of prefixes? Modem users will be more than happy with a /64, because they do not need to subnet. If one wants to share the modem connection for their home network, that home network is a single subnet and will do fine with a /64. Broadband home connections (cable/dsl) would do ok with a /64, too, for the same reason. Why would someone want a /68 (or whatever) for the living room, a /68 for the john, a /68 for the kitchen, a /68 for the garage? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 08:50:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11God2Q023992 for ; Fri, 1 Feb 2002 08:50:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11GodaL023991 for ipng-dist; Fri, 1 Feb 2002 08:50:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11GoZ2Q023984 for ; Fri, 1 Feb 2002 08:50:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13294 for ; Fri, 1 Feb 2002 08:50:49 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22892 for ; Fri, 1 Feb 2002 09:50:48 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA04938; Fri, 1 Feb 2002 17:50:46 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57674 from ; Fri, 1 Feb 2002 17:50:44 +0100 Message-Id: <3C5AC764.CE239814@hursley.ibm.com> Date: Fri, 01 Feb 2002 17:50:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: francis.arts@alcatel.be, ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure about Pekka's answer, because I'm not sure what the question is. The outer IPv4 packet is just a normal packet from the 6to4 router, so its IPv4 source address is the IPv4 address of the sending interface on the 6to4 router. The inner IPv6 packet has an IPv6 source address which is that of the originating IPv6 host. If the router is a normal 6to4 router, that will be an IPv6 address starting with 2002:v4addr where v4addr is the source IPv4 address of the 6to4 router. If the router is a 6to4 relay router, the IPv6 source address could be any valid unicast IPv6 address (except for a few odd cases such as link local). As Pekka says, this is an ngtrans topic. Brian Pekka Savola wrote: > > On Fri, 1 Feb 2002 francis.arts@alcatel.be wrote: > > When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not > > get answered. Consider the router that originates the IPv4 tunnel. Which > > IP address should this router use as the source IP addres in its IPv4 > > encapsulation header: > > > > * Should this address be the router id of this router? > > Or > > If router-id is V4ADDR in 2002:V4ADDR. > > > * Should the source IPv4 address be derived from the source IPv6 address > > Or > > ...? > > Yes. > > See RFC3056 Chapter 3: > > IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 > protocol type of 41, the same as has been assigned [MECH] for IPv6 > packets that are tunneled inside of IPv4 frames. The IPv4 header > contains the Destination and Source IPv4 addresses. One or both of > these will be identical to the V4ADDR field of an IPv6 prefix formed > as specified above (see section 5 for more details). The IPv4 packet > body contains the IPv6 header and payload. > > (btw, this is ngtrans, rather than ipng, material) > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 08:51:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11GpX2Q024009 for ; Fri, 1 Feb 2002 08:51:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11GpX1I024008 for ipng-dist; Fri, 1 Feb 2002 08:51:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11GpT2Q024001 for ; Fri, 1 Feb 2002 08:51:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01037 for ; Fri, 1 Feb 2002 08:51:44 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29924 for ; Fri, 1 Feb 2002 08:51:43 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g11GoR228151; Fri, 1 Feb 2002 18:50:27 +0200 Date: Fri, 1 Feb 2002 18:50:26 +0200 (EET) From: Pekka Savola To: Tomas Lund cc: Robert Elz , Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tomas Lund wrote: > On Fri, 1 Feb 2002, Robert Elz wrote: > > > | 3. Is it ok to use longer than a /64 for links ? > > > > That is, the suggestion isn't to pressure people to use /126 or something > > (as your #2 would do), nor to tell people that it isn't OK to use a /64 > > /127 seems alot better? Why waste 50%? /127 is wrong. There was discussion on this last November. I'll be sending short I-D on this to internet-drafts before Monday. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:05:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11H5J2Q024075 for ; Fri, 1 Feb 2002 09:05:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11H5J1b024074 for ipng-dist; Fri, 1 Feb 2002 09:05:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11H5C2Q024059; Fri, 1 Feb 2002 09:05:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15898; Fri, 1 Feb 2002 09:05:27 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05975; Fri, 1 Feb 2002 09:05:27 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g11H5Pe01320; Fri, 1 Feb 2002 09:05:25 -0800 (PST) Message-ID: <004501c1ab42$6ac485e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , , , Cc: "Charles E. Perkins" References: <3C5A7353.10705@nomadiclab.com> Subject: Re: [Monet] The semantics of the Routing Header? Date: Fri, 1 Feb 2002 09:03:48 -0800 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Related to the debate on the mobile-ip list on whether > MIPv6 should use Routing Header or some other mechanism > to carry the home address to a mobile node that is > away from home, I'd like to solicit for well grounded > opinions on the intended semantics of the Routing Header. > > To properly understand what I am really asking about we > must first make a distinction between two logical > entities, endpoints and locations. In the current > Internet architecture, both endpoints and locations are > identified with a single mechanism, i.e. with IP addresses. > However, they are conceptually different, as very well > pointed out by Noel Chiappa in > http://users.exis.net/~jnc/tech/endpoints.txt > In essense, a communication endpoint is an active > entity engadged in the communications, i.e. a party > who consumes messages and generates new ones. A location, > on the other hand, is a topological "place" within the > routing fabric. > I think there is something missing in this analysis. A communication endpoint requires more than just the address to identify it, it also requires the port. > Now, my question is fairly simple: Is the meaning of > the routing header to allow a packet to be sent through > a number of communicating hosts (end-points) or via a > specific path, identified by a set of locations? Or > is it both? > To me, it is fairly clear that the routing header is just to route through a determined set of intermediate forwarding nodes, i.e. routers, regardless of their communication status. The header does not nor should it require that a forwarding node be running a specific protocol and thus support traffic to a particular port in order to obtain forwarding service. > One way of pondering the question is to imagine that the > endpoints and locations had different name spaces. For > example, you could imagine that each host has a flat > name tag (HIT in HIP terminology), and the locations > are named according to the routing hierarchy as today. > Under such an architecture, would the routing header > contain addresses or these new name tags, or could > it contain a mixture of both? > > The reason why I am asking this is the scenario, which > Charlie Perkins has offered, where a packet is source > routed through a Mobile Node that is away from home. > According to his argumentation, in such case the > routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > > where the Care-of-Address is the current location of > the mobile node, and the Home Address is more like > the end-point identifier of the mobile node. I am > having hard time in clearly crasping the intended > semantic meaning of this construction. > I've been loosely following this discussion, and I think Charlie's argument has merit but I think it is orthogonal to what the semantics of the Routing Header should be. Currently, as Charlie has pointed out, the two functions are served by two header options. The MIP case may be unique enough that perhaps a new option is needed combining the CoA and HA. I don't really see this as being a general problem, though. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HZI2Q024264 for ; Fri, 1 Feb 2002 09:35:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11HZHae024263 for ipng-dist; Fri, 1 Feb 2002 09:35:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HZE2Q024256 for ; Fri, 1 Feb 2002 09:35:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13056 for ; Fri, 1 Feb 2002 09:35:30 -0800 (PST) Received: from sluis.cs.vu.nl (sluis.cs.vu.nl [192.31.231.174]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04173 for ; Fri, 1 Feb 2002 10:35:29 -0700 (MST) Received: from centaur.cs.vu.nl by sluis.cs.vu.nl with esmtp (Smail #71) id m16Whas-000OY1C; Fri, 1 Feb 2002 18:35 +0100 Received: from cs.vu.nl (localhost) by centaur.cs.vu.nl with esmtp (Smail #71) id m16Whas-0014QLC; Fri, 1 Feb 2002 18:35 +0100 Message-Id: To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Fri, 1 Feb 2002 08:33:21 -0800 ." <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill-py.sacramento.ca.us> Date: Fri, 01 Feb 2002 18:35:21 +0100 From: Philip Homburg Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your letter dated Fri, 1 Feb 2002 08:33:21 -0800 you wrote: >Philip Homburg wrote: >> What happens if an organization has a modem bank for dail-in? Do you >> hand out /64s or something larger? Suppose that you want to give each >> 'modem user' a fixed prefix, how soon do you run out of prefixes? > >Modem users will be more than happy with a /64, because they do not need >to subnet. > >Why would someone want a /68 (or whatever) for the living room, a /68 >for >the john, a /68 for the kitchen, a /68 for the garage? The kids get their own networks to play multi-person games, the light switches go on a separate network, any piece of hardware that is not completely secure should not be on a broadcast network, so the ADSL or cable modem, the wireless basestation, etc. each get their own networks. VPNs may require their own prefixes, etc. Philip Homburg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:44:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Hia2Q024284 for ; Fri, 1 Feb 2002 09:44:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11HiaVV024283 for ipng-dist; Fri, 1 Feb 2002 09:44:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HiX2Q024276 for ; Fri, 1 Feb 2002 09:44:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15875 for ; Fri, 1 Feb 2002 09:44:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22799 for ; Fri, 1 Feb 2002 09:44:44 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 09:45:33 -0800 From: "Tony Hain" To: "Robert Elz" , "Michel Py" Cc: "Brian E Carpenter" , "JJ Behrens" , "Keith Moore" , "Irina Dayal" , Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 09:44:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2651.1012549451@brandenburg.cs.mu.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > I find it almost impossible to work out where /80 comes from > ... But if there's something > supposedly magic about the last 48 bits (48 now is 100% irrelevant to > autoconf, so it cannot be that) it has escaped me. EUI-48 Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:50:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Hom2Q024301 for ; Fri, 1 Feb 2002 09:50:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11Hol7b024300 for ipng-dist; Fri, 1 Feb 2002 09:50:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Hoi2Q024293 for ; Fri, 1 Feb 2002 09:50:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24993 for ; Fri, 1 Feb 2002 09:50:59 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25503 for ; Fri, 1 Feb 2002 09:50:59 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 09:51:50 -0800 From: "Tony Hain" To: "Philip Homburg" , Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 09:50:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Philip Homburg wrote: > What happens if an organization has a modem bank for dail-in? > Do you hand > out /64s or something larger? Hand out a /64 or shorter depending on the customer. > Suppose that you want to give each 'modem user' > a fixed prefix, how soon do you run out of prefixes? If you assign a /48 to the pop and allocate /64's to the customers, you will run out when you exceed 65536 active users. If the pop has more ports than that, assign a /47. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:56:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Huc2Q024368 for ; Fri, 1 Feb 2002 09:56:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11HubVa024367 for ipng-dist; Fri, 1 Feb 2002 09:56:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HuW2Q024351 for ; Fri, 1 Feb 2002 09:56:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26341 for ; Fri, 1 Feb 2002 09:56:47 -0800 (PST) From: francis.arts@alcatel.be Received: from barao.cpqd.com.br (barao.cpqd.com.br [200.231.0.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22018 for ; Fri, 1 Feb 2002 10:56:44 -0700 (MST) Received: from fw-cpqd (dmz-int.cpqd.com.br [200.231.0.35]) by barao.cpqd.com.br (8.9.3/8.9.3) with SMTP id PAA22510 for ; Fri, 1 Feb 2002 15:54:24 -0200 Received: from gandalf.cpqd.com.br ([10.202.128.110]) by fw-cpqd; Fri, 01 Feb 2002 15:55:54 -0800 (PST) Received: from mail pickup service by mailsrv1.aquarius.cpqd.com.br with Microsoft SMTPSVC; Fri, 1 Feb 2002 15:50:59 -0200 Received: from fw-cpqd ([200.231.0.66]) by mailsrv1.aquarius.cpqd.com.br with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Feb 2002 10:01:54 -0200 Received: from conde.cpqd.com.br ([200.231.0.49]) by fw-cpqd; Fri, 01 Feb 2002 10:01:55 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by conde.cpqd.com.br (8.9.3/8.9.3) with ESMTP id KAA25102; Fri, 1 Feb 2002 10:00:23 -0200 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12923; Fri, 1 Feb 2002 05:02:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29968; Fri, 1 Feb 2002 04:02:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C082Q023168 for ; Fri, 1 Feb 2002 04:00:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11C08Jn023167 for ipng-dist; Fri, 1 Feb 2002 04:00:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C042Q023160 for ; Fri, 1 Feb 2002 04:00:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05703 for ; Fri, 1 Feb 2002 04:00:18 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03085 for ; Fri, 1 Feb 2002 05:00:17 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g11C0Ck17618 for ; Fri, 1 Feb 2002 13:00:12 +0100 (MET) To: ipng@sunroof.eng.sun.com Subject: RFC 3056 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 1 Feb 2002 13:00:10 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/01/2002 13:00:12, Serialize complete at 02/01/2002 13:00:12 Content-Type: multipart/alternative; boundary="=_alternative 0041EEDAC1256B53_=" X-OriginalArrivalTime: 01 Feb 2002 12:01:54.0134 (UTC) FILETIME=[3D6F1760:01C1AB18] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0041EEDAC1256B53_= Content-Type: text/plain; charset="us-ascii" Hello, When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not get answered. Consider the router that originates the IPv4 tunnel. Which IP address should this router use as the source IP addres in its IPv4 encapsulation header: * Should this address be the router id of this router? Or * Should the source IPv4 address be derived from the source IPv6 address Or ..? Thanks for any help you can provide, Francis. --=_alternative 0041EEDAC1256B53_= Content-Type: text/html; charset="us-ascii"
Hello,

When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not get answered. Consider the router that originates the IPv4 tunnel. Which IP address should this router use as the source IP addres in its IPv4 encapsulation header:

* Should this address be the router id of this router?
Or
* Should the source IPv4 address be derived from the source IPv6 address
Or
...?

Thanks for any help you can provide,

        Francis. --=_alternative 0041EEDAC1256B53_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 09:56:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Hua2Q024365 for ; Fri, 1 Feb 2002 09:56:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11Huabv024364 for ipng-dist; Fri, 1 Feb 2002 09:56:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HuU2Q024344 for ; Fri, 1 Feb 2002 09:56:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14114 for ; Fri, 1 Feb 2002 09:56:46 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28139 for ; Fri, 1 Feb 2002 09:56:46 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 09:57:36 -0800 From: "Tony Hain" To: "Philip Homburg" , Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 09:56:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Philip Homburg wrote: > The kids get their own networks to play multi-person games, the > light switches go on a separate network, any piece of hardware that is > not completely secure should not be on a broadcast network, > so the ADSL or > cable modem, the wireless basestation, etc. each get their > own networks. > VPNs may require their own prefixes, etc. This is why sites should be allocated /48s. There is no inherent reason to break into the interface id space for subnets. This is particularly true when the reason is simply to satisfy the draconian address conservation attitude required to extend the life of IPv4 until IPv6 can be deployed. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 10:02:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11I2P2Q025109 for ; Fri, 1 Feb 2002 10:02:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11I2PcM025108 for ipng-dist; Fri, 1 Feb 2002 10:02:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11I2M2Q025101 for ; Fri, 1 Feb 2002 10:02:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27297 for ; Fri, 1 Feb 2002 10:02:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15430 for ; Fri, 1 Feb 2002 11:02:35 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g11I0SQ28670; Fri, 1 Feb 2002 20:00:28 +0200 Date: Fri, 1 Feb 2002 20:00:28 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Philip Homburg , Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > > Suppose that you want to give each 'modem user' > > a fixed prefix, how soon do you run out of prefixes? > > If you assign a /48 to the pop and allocate /64's to the customers, you > will run out when you exceed 65536 active users. If the pop has more > ports than that, assign a /47. I'm broadening the topic to include all kinds of home users, e.g. xDSL, Cable etc. in addition to dial-in. This is in conflict with IAB/IESG recommendations for address assignments (draft-iesg-ipv6-addressing-recommendations-03.txt). A RIR policy issue, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 10:02:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11I2q2Q025143 for ; Fri, 1 Feb 2002 10:02:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11I2qqt025142 for ipng-dist; Fri, 1 Feb 2002 10:02:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11I2m2Q025135 for ; Fri, 1 Feb 2002 10:02:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21733 for ; Fri, 1 Feb 2002 10:03:03 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13532 for ; Fri, 1 Feb 2002 11:03:02 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA03472; Fri, 1 Feb 2002 18:06:29 GMT Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA10014; Fri, 1 Feb 2002 18:03:06 GMT Date: Fri, 1 Feb 2002 18:03:01 +0000 (GMT) From: Tim Chown To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > This is why sites should be allocated /48s. There is no inherent reason > to break into the interface id space for subnets. This is particularly > true when the reason is simply to satisfy the draconian address > conservation attitude required to extend the life of IPv4 until IPv6 can > be deployed. If that's static /48's, the /29 boundary will need revision...(and certainly a /35 would be useless to any medium ISP). Would you apply the RFC3194 0.8 HD ratio to subnets within a single ISP? I don't see that provider networks would be flat or near 100% utilisation as you suggest in your previous email. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 10:18:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IHx2Q026841 for ; Fri, 1 Feb 2002 10:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11IHx5X026840 for ipng-dist; Fri, 1 Feb 2002 10:17:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IHu2Q026833 for ; Fri, 1 Feb 2002 10:17:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27638 for ; Fri, 1 Feb 2002 10:18:11 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12471 for ; Fri, 1 Feb 2002 11:18:11 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 10:18:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE8E@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGrSJSvgNlVf73uS/m5utMZnNGDrwAAxD7A From: "Michel Py" To: "Philip Homburg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g11IHu2Q026834 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Philip Homburg wrote: > The kids get their own networks to play multi-person games, the > light switches go on a separate network, any piece of hardware > that is not completely secure should not be on a broadcast > network, so the ADSL or cable modem, the wireless basestation, > etc. each get their own networks. VPNs may require their own > prefixes, etc. So, the $100 IPv6 linksys home router is going to come with a layer3, vlan capable switch. (I assume that one would not want to have a physical switch for each subnet, therefore vlans are the answer). Possibly stateful packet inspection between the home subnets. I guess there is nothing wrong with running 802.1Q over 802.11 either. It looks that we need to pack a Cat5505 with RSM into a smaller box. One question: Who is going to configure the vlans and the access-lists between them? Joe customer? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 10:42:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IgM2Q027278 for ; Fri, 1 Feb 2002 10:42:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11IgMoo027277 for ipng-dist; Fri, 1 Feb 2002 10:42:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IgI2Q027270 for ; Fri, 1 Feb 2002 10:42:18 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06145 for ; Fri, 1 Feb 2002 10:42:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06586 for ; Fri, 1 Feb 2002 10:42:31 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g11Idv918166; Fri, 1 Feb 2002 13:39:57 -0500 (EST) Message-Id: <200202011839.g11Idv918166@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Philip Homburg" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Fri, 01 Feb 2002 08:33:21 PST." <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill-py.sacramento.ca.us> Date: Fri, 01 Feb 2002 13:39:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I had in mind was that if someone felt like re-inventing the wheel > and create a new autoconf, it would be extremely difficult not to use > the 48-bit MAC address (nobody would buy having ARP for IPv6), therefore > going beyong /80 would be very difficult. We're talking about a technology that will hopefully be used for decades. We don't want to wire assumptions about the sizes of MAC addresses during that time into the IPv6 architecture. To me it seems entirely plausible that networks consisting of large numbers of point-to-point links, assembled into trees, will be all the rage in a few years. Even Ethernet is becoming more a point-to-point technology rather than a bus technology. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 10:57:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Ivd2Q027380 for ; Fri, 1 Feb 2002 10:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11IvdEG027379 for ipng-dist; Fri, 1 Feb 2002 10:57:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Iva2Q027372 for ; Fri, 1 Feb 2002 10:57:36 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12372 for ; Fri, 1 Feb 2002 10:57:50 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA13508 for ; Fri, 1 Feb 2002 10:57:48 -0800 (PST) Received: (qmail 19165 invoked from network); 1 Feb 2002 18:57:40 -0000 Received: from p50804a89.dip.t-dialin.net (HELO worker.muc.bieringer.de) (80.128.74.137) by mail.bieringer.de with SMTP; 1 Feb 2002 18:57:40 -0000 Date: Fri, 01 Feb 2002 19:57:36 +0100 From: Peter Bieringer To: Philip Homburg , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-ID: <30380000.1012589856@localhost> In-Reply-To: References: <2B81403386729140A3A899A8B39B046406C27E@server2000.arneill- py.sacramento.ca.us> <22735.1012464548@brandenburg.cs.mu.OZ.AU> <38720000.1012506916@localhost> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Friday, February 01, 2002 01:04:48 PM +0100 Philip Homburg wrote: > In your letter dated Thu, 31 Jan 2002 20:55:16 +0100 you wrote: >> --On Thursday, January 31, 2002 03:09:08 PM +0700 Robert Elz >> wrote: >>> I probably wouldn't either, though we don't want to totally forget >>> allocation efficiency - the way we make sure that IPv6 never runs >>> out is to always make sure we justify every allocation (which >>> doesn't mean organisations need to justify their need for a /48 - >> >>> but I'd certainly be making any organisation asking for a 2nd one >>> (in the same aggregatable block, >> >> If this will happen, which organisation would this be? Compared >> with current IPv4 /48 with the 16 bits for SLA is similar to a >> IPv4 Class A network. > > What happens if an organization has a modem bank for dail-in? Do > you hand out /64s or something larger? Suppose that you want to > give each 'modem user' a fixed prefix, how soon do you run out of > prefixes? Where is the problem? Today they got *one* *dynamic* IPv4 address and have to be happy with it. Connection of additional internal hosts requires masquerading, causing perhaps problems and had (without dedicated port forwarding) no capability to direct traffic from outside to inside. In IPv6 future, they will get one /64 prefix and can connect a lot of toasters, VCRs, TVs, battery chargers, light switches and so on. All devices get a *global* IPv6 address. And in case of no IPv6 firewalling, all this devices can be connected directly from outside. --> normally a big advantage not mention any potential security issues in network-connected toasters here now ;-) People have only to think that they do no longer need to take care about Layer 3 routing and addresses in their home networks, they only need a Layer 2 switch and the "IPv6 access device". Your described scenario only cause a problem if someone really wants to Layer 3 route in his home network - but how many really want to do this or need this? Conclusion: people have to think about network redesigning from dedicated small IPv4 network islands to bigger full switched IPv6 networks. Note: broadcast traffic is reduced/eliminated in IPv6 because of Layer 3 multicast mechanism, which should be also mapped into Layer 2 multicast addresses. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 11:24:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11JOn2Q027511 for ; Fri, 1 Feb 2002 11:24:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11JOm3o027510 for ipng-dist; Fri, 1 Feb 2002 11:24:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11JOj2Q027503 for ; Fri, 1 Feb 2002 11:24:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19943 for ; Fri, 1 Feb 2002 11:24:59 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26851 for ; Fri, 1 Feb 2002 11:24:59 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 11:25:49 -0800 From: "Tony Hain" To: "Pekka Savola" Cc: "Philip Homburg" , Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 11:24:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > I'm broadening the topic to include all kinds of home users, e.g. > xDSL, Cable etc. in addition to dial-in. No problem as the actual implementation at the consumer end is probably similar. There will be some device between the provider network and the consumer network, be that dial or always-on. The device needs either a /48 so it can provide subnet based routing, or a /64 so it can provide a bridged subnet capability. > This is in conflict with IAB/IESG recommendations for address > assignments > (draft-iesg-ipv6-addressing-recommendations-03.txt). A RIR > policy issue, > though. I assume you mean RFC3177... but the point is that it is aligned. Except in the private network context, there is never a reason to believe that only a single device is connected, even a cell phone might be a router/bridge. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 11:43:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11JhF2Q027545 for ; Fri, 1 Feb 2002 11:43:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11JhFAW027544 for ipng-dist; Fri, 1 Feb 2002 11:43:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11JhC2Q027537 for ; Fri, 1 Feb 2002 11:43:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27385 for ; Fri, 1 Feb 2002 11:43:26 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03929 for ; Fri, 1 Feb 2002 11:43:26 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 11:44:16 -0800 From: "Tony Hain" To: "Tim Chown" Cc: Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 11:43:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > If that's static /48's, the /29 boundary will need revision...(and > certainly a /35 would be useless to any medium ISP). Did the term 'slow-start' get lost somewhere? As I understand rir policy, the /35 was never intended to be the only allocation a serious ISP would get. Static vs dynamic is a non-issue, because either there are enough prefixes to route the currently connected customers or there aren't. If a service provider wants to allocate prefixes to customers that aren't connected, they will need a larger block than the one that allocates dynamically based on connected status. > > Would you apply the RFC3194 0.8 HD ratio to subnets within a > single ISP? > I don't see that provider networks would be flat or near 100% > utilisation > as you suggest in your previous email. Within the context of a pop, why not? The only reason this would not be the case is when a provider considers the allocation to be disjoint from current connected status (ie: static assignment) and the measurement is done on the connected set rather than the allocated set. The HD ratio should be calculated on the allocated set no matter if that is static or dynamic. I can already hear the 'what about renumbering nodes?' question. There is no reason for this to be an issue. Address use is defined to match the smallest scope appropriate for the connection, so intra-site/on-link communications will be immune to changes in the global prefix. If a site is currently disconnected from the service provider, there is no reason for it to have a global prefix floating around. The only reasons for an ISP to make static prefix assignments would be if the site wanted stable DNS entries, but with a decent DDNS infrastructure that is not even required. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 12:00:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11K0b2Q027673 for ; Fri, 1 Feb 2002 12:00:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11K0bbN027672 for ipng-dist; Fri, 1 Feb 2002 12:00:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11K0Y2Q027665 for ; Fri, 1 Feb 2002 12:00:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12199 for ; Fri, 1 Feb 2002 12:00:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10300 for ; Fri, 1 Feb 2002 12:00:47 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 12:01:38 -0800 From: "Tony Hain" To: "Peter Bieringer" , "Philip Homburg" , Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 12:00:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <30380000.1012589856@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Bieringer wrote: > Where is the problem? > > Today they got *one* *dynamic* IPv4 address and have to be happy with > it. Connection of additional internal hosts requires masquerading, > causing perhaps problems and had (without dedicated port forwarding) > no capability to direct traffic from outside to inside. > > In IPv6 future, they will get one /64 prefix and can connect a lot of > toasters, VCRs, TVs, battery chargers, light switches and so on. All > devices get a *global* IPv6 address. > And in case of no IPv6 firewalling, all this devices can be connected > directly from outside. > > --> normally a big advantage > not mention any potential security issues in network-connected > toasters here now ;-) All sites have a /64 and a /48 prefix available to them *before* they make any global connection; link-local & site-local. For those devices where global connectivity may cause undue security concerns (like a light switch) there is absolutely no reason they need to pay attention to any global prefixes that may be in the RA. They will still be perfectly functional auto-configuring IPv6 devices, they just won't have global access. If privacy is the intended policy, it is easier to implement and more secure to have only the nodes that need global addresses listen to them in the RA, than to rely on a NAT/filter which is most likely confused because its state updates take longer than the dynamics of connections. > > People have only to think that they do no longer need to take care > about Layer 3 routing and addresses in their home networks, they only > need a Layer 2 switch and the "IPv6 access device". We have an allocation mechanism for the simple layer-2 network, a /64, and a mechansim for those who want a complex layer-3, a /48. > > Your described scenario only cause a problem if someone really wants > to Layer 3 route in his home network - but how many really want to do > this or need this? It doesn't matter, the mechansim exists and is sufficient for all but a handful of multi-national corporations. > > > Conclusion: people have to think about network redesigning from > dedicated small IPv4 network islands to bigger full switched IPv6 > networks. To be precise, people should think about designing the network topology to meet the functional requirements. > > Note: broadcast traffic is reduced/eliminated in IPv6 because of > Layer 3 multicast mechanism, which should be also mapped into Layer 2 > multicast addresses. Layer-2 broadcasts are still appropriate for some uses, so don't assume that just because we can do without them at layer-3 that we should get rid of them at layer-2 as well. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 13:50:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11LoE2Q027804 for ; Fri, 1 Feb 2002 13:50:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11LoEZh027803 for ipng-dist; Fri, 1 Feb 2002 13:50:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11LoB2Q027796 for ; Fri, 1 Feb 2002 13:50:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28154 for ; Fri, 1 Feb 2002 13:50:26 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18064 for ; Fri, 1 Feb 2002 13:50:26 -0800 (PST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 13:50:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE8F@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGrVs6bar29poVxRJSaaYEciMLroQAExHeA From: "Michel Py" To: "Tony Hain" , "Pekka Savola" Cc: "Philip Homburg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g11LoC2Q027797 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Pekka Savola wrote: >> I'm broadening the topic to include all kinds of home users, e.g. >> xDSL, Cable etc. in addition to dial-in. > Tony Hain wrote: > No problem as the actual implementation at the consumer end is probably > similar. There will be some device between the provider network and the > consumer network, be that dial or always-on. The device needs either a > /48 so it can provide subnet based routing, or a /64 so it can provide > a bridged subnet capability. I concur with Tony. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 13:54:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11LsE2Q027837 for ; Fri, 1 Feb 2002 13:54:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11LsEDu027836 for ipng-dist; Fri, 1 Feb 2002 13:54:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11LsB2Q027826 for ; Fri, 1 Feb 2002 13:54:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29485 for ; Fri, 1 Feb 2002 13:54:26 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16515 for ; Fri, 1 Feb 2002 14:54:25 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA04504; Fri, 1 Feb 2002 21:57:52 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA04357; Fri, 1 Feb 2002 21:54:29 GMT Date: Fri, 1 Feb 2002 21:54:23 +0000 (GMT) From: Tim Chown To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > Did the term 'slow-start' get lost somewhere? As I understand rir > policy, the /35 was never intended to be the only allocation a serious > ISP would get. Static vs dynamic is a non-issue, because either there > are enough prefixes to route the currently connected customers or there > aren't. If a service provider wants to allocate prefixes to customers > that aren't connected, they will need a larger block than the one that > allocates dynamically based on connected status. The question is, if a service provider wants to follow the recommendation for a /48 allocation for a connected site, and the provider wants to offer static /48's to always-on sites, won't it hit trouble whether it is using a /35 or a /29? If you say "either there are enough prefixes to route the currently connected customers or there aren't" then you're saying either we will have ISP's out there who can allocate static /48's to sites, or we won't. It'd be nice if the answer was that we will... even if that provider has a million customers. I feel we're in a slow start inside a slow start and that will be harmful, because providers won't offer the /48 because there's not enough headroom. OK, a static /64 is better than today's (typical) dyanmic single IPv4 address, I agree :-) > Within the context of a pop, why not? The only reason this would not be > the case is when a provider considers the allocation to be disjoint from > current connected status (ie: static assignment) and the measurement is > done on the connected set rather than the allocated set. The HD ratio > should be calculated on the allocated set no matter if that is static > or dynamic. I observe, as a BT ADSL customer, 9 hops from my NAT box to the BT Internet gateway. The question then is whether the provider can build an architecture to 100% utilise the address space (unlikely), or if not to what extent the address space can be used, in a wide area deployment (e.g. for BT xDSL across the UK)? It should be better than RFC3194, but how much better? > I can already hear the 'what about renumbering nodes?' question. There > is no reason for this to be an issue. Address use is defined to match > the smallest scope appropriate for the connection, so intra-site/on-link > communications will be immune to changes in the global prefix. If a site > is currently disconnected from the service provider, there is no reason > for it to have a global prefix floating around. The only reasons for an > ISP to make static prefix assignments would be if the site wanted stable > DNS entries, but with a decent DDNS infrastructure that is not even > required. My own view is that a static prefix is very important. Certainly a "decent DDNS infrastructure" would have to deal with significantly more renumbering, and more rapid renumbering, application awareness, more lookups with lower TTLs, firewalling problems (I set up access to let my friend copy files from my MP3 server, but oops his prefix just changed), issues where the Mobile IPv6 home agent/prefix is really in the home, etc. Thus the DDNS infrastructure has to fit the model where the servers are on the networks with the dynamic addresses. It just seems so much easier to assume static home prefixes. But if we want that, the implications for the providers' allocations needs to be addressed. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 14:29:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11MT52Q027879 for ; Fri, 1 Feb 2002 14:29:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11MT443027878 for ipng-dist; Fri, 1 Feb 2002 14:29:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11MT12Q027871 for ; Fri, 1 Feb 2002 14:29:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10954 for ; Fri, 1 Feb 2002 14:29:17 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00632 for ; Fri, 1 Feb 2002 15:29:16 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 14:29:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE91@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGra3fbW6zxCRCZR8CBq00lKEhJYgAAUOVg From: "Michel Py" To: "Tim Chown" , "Tony Hain" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g11MT22Q027872 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tim Chowm wrote: > The question is, if a service provider wants to follow the recommendation > for a /48 allocation for a connected site, and the provider wants to > offer static /48's to always-on sites, won't it hit trouble whether it is > using a /35 or a /29? If you say "either there are enough prefixes to > route the currently connected customers or there aren't" then you're > saying either we will have ISP's out there who can allocate static /48's > to sites, or we won't. It'd be nice if the answer was that we will... > even if that provider has a million customers. Tim, I fail to see your point here. Lots of people will settle with a dynamic /64. (they won't even pay 5 bucks a month more to get a static one). Some will want a static /64 because they have thap mp3 server that their want their buddies to access and also because they want to be able to telnet to their linux box from the office. Let's say the ISP will sell the static /64 prefix for $5/mo more. Finally, a small number of seriously sick geeks (count me in) that want their refrigerator to be the only IPv6 device on its very own subnet, and of course businesses, will request a static /48. That might cost twice as much as a /64, or more. Given that a /29 is half-a-million /48 prefixes, and with the most pessimistic figures about the /64 to /48 ratio, a /29 will serve a million customers with ease. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 15:08:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11N8C2Q027933 for ; Fri, 1 Feb 2002 15:08:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11N8BNt027932 for ipng-dist; Fri, 1 Feb 2002 15:08:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11N882Q027925 for ; Fri, 1 Feb 2002 15:08:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24264 for ; Fri, 1 Feb 2002 15:08:22 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15173 for ; Fri, 1 Feb 2002 16:08:21 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 15:09:08 -0800 From: "Tony Hain" To: "Tim Chown" Cc: Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 15:08:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > The question is, if a service provider wants to follow the > recommendation > for a /48 allocation for a connected site, and the provider wants to > offer static /48's to always-on sites, won't it hit trouble > whether it is > using a /35 or a /29? If you say "either there are enough > prefixes to > route the currently connected customers or there aren't" then > you're saying > either we will have ISP's out there who can allocate static > /48's to sites, > or we won't. It'd be nice if the answer was that we will... > even if that > provider has a million customers. To serve a million the service provider will need at least a /28, and probably a /27 where is the problem? If you are assuming that the rir's won't allocate a /27 to a provider that can document allocation to a million customers then we have a problem with rir policy not being applied consistently with what is documented. > > I feel we're in a slow start inside a slow start and that > will be harmful, > because providers won't offer the /48 because there's not > enough headroom. > OK, a static /64 is better than today's (typical) dyanmic single IPv4 > address, I agree :-) There are active discussions about changing the slow-start. We will have to see what happens, but I believe a /32 is likely. I really doubt that a provider would have a hard time getting a /27 if they walked in with a list of a million customers and said here is our plan for allocating /48's statically to each of them. As I understand it, the rir policy is intended to ensure efficient allocation, not dictate a business practice of dynamic allocations. If you have evidence to the contrary please speak up. > > I observe, as a BT ADSL customer, 9 hops from my NAT box to > the BT Internet > gateway. Sounds like a personal problem of provider selection... ;) My dsl is 3 hops from the nearest border router. 1 * * * Request timed out. 2 18 ms 18 ms 18 ms a4-3-1.evrtwa1-aa2.bbnplanet.net [4.24.255.193] 3 20 ms 20 ms 18 ms p7-0.evrtwa1-cr2.bbnplanet.net [4.0.79.129] 4 18 ms 18 ms 24 ms p3-0.evrtwa1-br2.bbnplanet.net [4.24.5.109] > The question then is whether the provider can build an > architecture to 100% utilise the address space (unlikely), or > if not to > what extent the address space can be used, in a wide area > deployment (e.g. > for BT xDSL across the UK)? It should be better than > RFC3194, but how > much better? CAN or WILL ?? It is certainly possible and easy to build complex infrastructures that don't scale well, but usually hard to build simple ones that naturally align with growth. One of the big problems I see from a long-term perspective with static assignments is 'how portable are the addresses?' If customers can move around the topology and keep the same address, the complexity goes way up and the HD ratio goes way down (actually if you treated the entire /28-48 as a single flat-route, the HD ration could hit 100%). If on the other hand the addresses were static with topology, it would be fairly straight-forward to align the sub-allocations along with population/pop-density (a town with ~1000 residents won't need more than a /38). > My own view is that a static prefix is very important. > Certainly a "decent > DDNS infrastructure" would have to deal with significantly > more renumbering, > and more rapid renumbering, application awareness, more > lookups with lower > TTLs, firewalling problems (I set up access to let my friend > copy files > from my MP3 server, but oops his prefix just changed), issues > where the > Mobile IPv6 home agent/prefix is really in the home, etc. > Thus the DDNS > infrastructure has to fit the model where the servers are on > the networks > with the dynamic addresses. It just seems so much easier to > assume static > home prefixes. But if we want that, the implications for > the providers' > allocations needs to be addressed. I agree and would be happy if all service providers were enlightened enough to *want* to provide static prefixes. If someone with a million existing customers has tried to show the rir's a plan for a static prefix assignment network and failed, I would like to know so a few of us can start working the issue. In any case I believe a robust ddns is required, and would prefer to see that as an edge service (ie: set-top) with the access device providing a nice, stable, single-point-needing-auth server for local devices that come and go on a frequent basis. It also makes the problem of ddns auth within the home easier because that can all be based on site-local addresses which the edge device knows didn't come through it from the public side. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 15:41:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Nfe2Q028020 for ; Fri, 1 Feb 2002 15:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11NfdDH028019 for ipng-dist; Fri, 1 Feb 2002 15:41:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Nfa2Q028012 for ; Fri, 1 Feb 2002 15:41:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23000 for ; Fri, 1 Feb 2002 15:41:51 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26646 for ; Fri, 1 Feb 2002 16:41:50 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA04835; Fri, 1 Feb 2002 23:45:17 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA14491; Fri, 1 Feb 2002 23:41:54 GMT Date: Fri, 1 Feb 2002 23:41:48 +0000 (GMT) From: Tim Chown To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: <2B81403386729140A3A899A8B39B046405DE91@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Michel Py wrote: > I fail to see your point here. Lots of people will settle with a dynamic > /64. (they won't even pay 5 bucks a month more to get a static one). As Pekka pointed out, in draft-iesg-ipv6-addressing-recommendations-03.txt it states: "In particular, we recommend: - Home network subscribers, connecting through on-demand or always-on connections should receive a /48." OK, so it is a recommendation, and ISP's can, if they choose, offer a static (or dynamic) /64, at whatever price they choose. (One comment for the IESG here is that in only one example is static allocation specifically mentioned; perhaps this should be considered for the document as a whole?) > Some will want a static /64 because they have thap mp3 server that > their want their buddies to access and also because they want to be able > to telnet to their linux box from the office. Let's say the ISP will > sell the static /64 prefix for $5/mo more. I think the market forces will lead to static /64's being available free of charge. There will be enough providers who can offer that for free, that those charging extra will lose business. While the recommendation may be a /48 (which may of course be subject to a charge by some providers) it's questionable at present as to whether any home networks would use it in the early deployment. > Given that a /29 is half-a-million /48 prefixes, and with the most > pessimistic figures about the /64 to /48 ratio, a /29 will serve a > million customers with ease. You assume that the /29 can be deployed in such a way that there is 100% utilisation. Is that really the case? (If I consider how a /29 may be used by a national academic research network provider, then the regionalisation of the networks mean it won't be, and on top of that you would presumably be making an address plan with growth in mind, e.g. for regional PoPs). Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 16:16:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g120GM2Q028180 for ; Fri, 1 Feb 2002 16:16:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g120GMWL028179 for ipng-dist; Fri, 1 Feb 2002 16:16:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g120GJ2Q028172 for ; Fri, 1 Feb 2002 16:16:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16227 for ; Fri, 1 Feb 2002 16:16:14 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07365 for ; Fri, 1 Feb 2002 17:16:12 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA05315; Sat, 2 Feb 2002 00:19:40 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA17773; Sat, 2 Feb 2002 00:16:16 GMT Date: Sat, 2 Feb 2002 00:16:11 +0000 (GMT) From: Tim Chown To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > To serve a million the service provider will need at least a /28, and > probably a /27 where is the problem? If you are assuming that the rir's > won't allocate a /27 to a provider that can document allocation to a > million customers then we have a problem with rir policy not being > applied consistently with what is documented. That's fine - my question was, because of the regionalisation and scoping for growth in network deployment, whether a /27 was enough (if you did use RFC3194 and its 0.8 HD ration you'd need a /23 for 1 million objects, but given the provider is in sole control of one network, I agree it should be far more efficient). > There are active discussions about changing the slow-start. We will have > to see what happens, but I believe a /32 is likely. I really doubt that > a provider would have a hard time getting a /27 if they walked in with a > list of a million customers and said here is our plan for allocating > /48's statically to each of them. As I understand it, the rir policy is > intended to ensure efficient allocation, not dictate a business practice > of dynamic allocations. If you have evidence to the contrary please > speak up. No, just an observation that the static/dynamic issue is not discussed in the IESG recommendations document. Perhaps it shouldn't be, but if providers read it, some reference may be useful (static /64 is mentioned for mobile networks, but of the five example recommendations, only that one explicitly says static). I would hope registries would not refuse an allocation based on the fact that they wished to make static allocations, if say only 75% of their customers were connected at one time and they could thus save a few bits of space by dynamic allocations. (The question then is why would a provider use dynamic allocations - presumably as a means to resize/juggle their network, though at present it's often used, even with free ddns services available, to deter people from running services from their home networks, which is exactly what we want IPv6 for...). > > I observe, as a BT ADSL customer, 9 hops from my NAT box to > > the BT Internet > > gateway. > > Sounds like a personal problem of provider selection... ;) > My dsl is 3 hops from the nearest border router. I didn't say BT Openworld was the best :-) I recall it was more hops until recently, and that for one trace I hit the default 30 hop limit...(!) But it's an indication that address utlisation won't be as good as people may hope? > ...... One of the big problems I see > from a long-term perspective with static assignments is 'how portable > are the addresses?' If customers can move around the topology and keep > the same address, the complexity goes way up and the HD ratio goes way > down (actually if you treated the entire /28-48 as a single flat-route, > the HD ration could hit 100%). If on the other hand the addresses were > static with topology, it would be fairly straight-forward to align the > sub-allocations along with population/pop-density (a town with ~1000 > residents won't need more than a /38). I was assuming the static addresses were aligned with topology. Then the premise would be that your IPv6 prefix is static for the home you are in, if you keep the same provider. Having considered an addressing plan for a national academic network, I don't know how (say) a plan for a BT Openworld IPv6 deployment might look (apart from more complicated than your provider's, I expect!). The static prefix I agree has implications for the provider in planning the deployment, and their ability to reshuffle their addressing scheme as the topology and regional demand changes. Perhaps the IESG proposal should have a section on this, if it's deemed appropriate and revelant? Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 1 16:20:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g120Kv2Q028203 for ; Fri, 1 Feb 2002 16:20:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g120Kvnl028202 for ipng-dist; Fri, 1 Feb 2002 16:20:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g120Kr2Q028195 for ; Fri, 1 Feb 2002 16:20:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17546 for ; Fri, 1 Feb 2002 16:21:08 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08973 for ; Fri, 1 Feb 2002 17:21:07 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Feb 2002 16:21:58 -0800 From: "Tony Hain" To: "Tim Chown" , "Michel Py" Cc: Subject: RE: IPv6 Addr/Prefix clarification Date: Fri, 1 Feb 2002 16:21:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > You assume that the /29 can be deployed in such a way that there is > 100% utilisation. Is that really the case? (If I consider how a /29 > may be used by a national academic research network provider, then > the regionalisation of the networks mean it won't be, and on top of > that you would presumably be making an address plan with growth in > mind, e.g. for regional PoPs). And you are arguing that the national academic research network provider needs more than 10 bits to serve its customers. While this is probably true for the IPv4 space since the customers acquired their allocations independently from the provider and are therefore disjoint, consider that the process of moving allows the provider to structure the boundaries according to density. If your argument is that this does not align perfectly with current topology, how much of that could/would be fixed if address management required it? In other words, how much of current topology is there because it can be as opposed to it needs to be? Granted there will be cases where topology can't be perfectly aligned to achieve 100% allocation efficiency, but I don't see anyone demanding 100%. Have you tried to get an allocation large enough to cover the network by allocating /48's to the current customers? If so what was the response? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 01:32:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g129Wv2Q028821 for ; Sat, 2 Feb 2002 01:32:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g129WvEG028820 for ipng-dist; Sat, 2 Feb 2002 01:32:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g129Wr2Q028813 for ; Sat, 2 Feb 2002 01:32:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29028 for ; Sat, 2 Feb 2002 01:33:09 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29193 for ; Sat, 2 Feb 2002 02:32:54 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 02 Feb 2002 15:19:05 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g129WNm13742 for ; Sat, 2 Feb 2002 15:02:46 +0530 Reply-To: From: "Murugan KAT" To: Subject: RE: IPv6 Addr/Prefix clarification Date: Sat, 2 Feb 2002 15:18:52 +0530 Message-Id: <000001c1abce$d2c93960$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, As per ND specification the Neighbor Advertisement message contains "O" Flag (OverRide flag). What is the purpose of this flag. Or when the nodes is supposed set this Flag. Or when the nodes are not supposed to set this flag. I suppose whenever the receiver finds a difference between the sent link address and the address what it has in its ND cache it can modify the value. Why is this extra bit...? Thanks, KAT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 01:34:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g129Y92Q028838 for ; Sat, 2 Feb 2002 01:34:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g129Y9i6028837 for ipng-dist; Sat, 2 Feb 2002 01:34:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g129Y52Q028830 for ; Sat, 2 Feb 2002 01:34:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17446 for ; Sat, 2 Feb 2002 01:34:21 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29366 for ; Sat, 2 Feb 2002 02:34:19 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 02 Feb 2002 15:20:25 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g129Y6m13801 for ; Sat, 2 Feb 2002 15:04:06 +0530 Reply-To: From: "Murugan KAT" To: Subject: ND - Neighbor Adv - 'O' Flag - clarification Date: Sat, 2 Feb 2002 15:20:35 +0530 Message-Id: <000101c1abcf$106ddd20$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, As per ND specification the Neighbor Advertisement message contains "O" Flag (OverRide flag). What is the purpose of this flag. Or when the nodes is supposed set this Flag. Or when the nodes are not supposed to set this flag. I suppose whenever the receiver finds a difference between the sent link address and the address what it has in its ND cache it can modify the value. Why is this extra bit...? Thanks, KAT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 02:27:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12ART2Q028936 for ; Sat, 2 Feb 2002 02:27:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g12ARTgg028935 for ipng-dist; Sat, 2 Feb 2002 02:27:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12ARQ2Q028928 for ; Sat, 2 Feb 2002 02:27:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02318 for ; Sat, 2 Feb 2002 02:27:41 -0800 (PST) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09489 for ; Sat, 2 Feb 2002 03:27:41 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (1672 bytes) by ensemada.lava.net; Sat, 2 Feb 2002 00:26:20 -1000 (HST) via sendmail [esmtp] id for Date: Sat, 2 Feb 2002 00:26:15 -1000 (HST) From: Antonio Querubin To: Tony Hain cc: Peter Bieringer , Philip Homburg , Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > We have an allocation mechanism for the simple layer-2 network, a /64, > and a mechansim for those who want a complex layer-3, a /48. > > > > > Your described scenario only cause a problem if someone really wants > > to Layer 3 route in his home network - but how many really want to do > > this or need this? > > It doesn't matter, the mechansim exists and is sufficient for all but a > handful of multi-national corporations. I suspect the practice of assigning a /48 for every complex layer-3 network isn't scalable for many medium and large service providers. The number of service providers with more than 65536 clients or customers is not just a handful. I would also suggest that many of them aren't even multi-national. The ISP stats at Boardwatch for example suggest the existance of many providers that might find this allocation mechanism to be impractical or wasteful of address space based on the size of their customer base. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 02:39:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12Adt2Q028979 for ; Sat, 2 Feb 2002 02:39:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g12Adsm4028978 for ipng-dist; Sat, 2 Feb 2002 02:39:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12Adp2Q028971 for ; Sat, 2 Feb 2002 02:39:51 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21367 for ; Sat, 2 Feb 2002 02:40:07 -0800 (PST) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08153 for ; Sat, 2 Feb 2002 02:40:06 -0800 (PST) Received: from malasada.lava.net ([64.65.64.17]) (1197 bytes) by ensemada.lava.net; Sat, 2 Feb 2002 00:40:04 -1000 (HST) via sendmail [esmtp] id for Date: Sat, 2 Feb 2002 00:40:04 -1000 (HST) From: Antonio Querubin To: Tony Hain cc: Peter Bieringer , Philip Homburg , Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2 Feb 2002, Antonio Querubin wrote: > I suspect the practice of assigning a /48 for every complex layer-3 > network isn't scalable for many medium and large service providers. The > number of service providers with more than 65536 clients or customers is ^^^^^ Oops! What am I thinking? Change that to 8192 as we're really butting up against the size of the space between /35 and /48, Reality is probably somewhere between 8192 and 65536. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 08:58:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12GwQ2Q029399 for ; Sat, 2 Feb 2002 08:58:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g12GwQuP029398 for ipng-dist; Sat, 2 Feb 2002 08:58:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12GwM2Q029391 for ; Sat, 2 Feb 2002 08:58:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12646 for ; Sat, 2 Feb 2002 08:58:37 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13273 for ; Sat, 2 Feb 2002 09:58:36 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA07690; Sat, 2 Feb 2002 17:02:03 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA03871; Sat, 2 Feb 2002 16:58:40 GMT Date: Sat, 2 Feb 2002 16:58:34 +0000 (GMT) From: Tim Chown To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Good points Tony - I guess we will have to wait until a large provider puts in a significant request, which may be some time yet. There are certainly more homes than universities+colleges (though of course most universities offer dialup to stduent homes :-) Tim On Fri, 1 Feb 2002, Tony Hain wrote: > And you are arguing that the national academic research network provider > needs more than 10 bits to serve its customers. While this is probably > true for the IPv4 space since the customers acquired their allocations > independently from the provider and are therefore disjoint, consider > that the process of moving allows the provider to structure the > boundaries according to density. If your argument is that this does not > align perfectly with current topology, how much of that could/would be > fixed if address management required it? In other words, how much of > current topology is there because it can be as opposed to it needs to > be? Granted there will be cases where topology can't be perfectly > aligned to achieve 100% allocation efficiency, but I don't see anyone > demanding 100%. Have you tried to get an allocation large enough to > cover the network by allocating /48's to the current customers? If so > what was the response? > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 2 11:58:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12Jwa2Q029564 for ; Sat, 2 Feb 2002 11:58:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g12JwasN029563 for ipng-dist; Sat, 2 Feb 2002 11:58:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g12JwX2Q029556 for ; Sat, 2 Feb 2002 11:58:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09192 for ; Sat, 2 Feb 2002 11:58:47 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16101 for ; Sat, 2 Feb 2002 12:58:46 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g12Jw9006249; Sat, 2 Feb 2002 21:58:09 +0200 Date: Sat, 2 Feb 2002 21:58:09 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Tim Chown , Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Feb 2002, Tony Hain wrote: > Tim Chown wrote: > > If that's static /48's, the /29 boundary will need revision...(and > > certainly a /35 would be useless to any medium ISP). > > Did the term 'slow-start' get lost somewhere? As I understand rir > policy, the /35 was never intended to be the only allocation a serious > ISP would get. Static vs dynamic is a non-issue, because either there > are enough prefixes to route the currently connected customers or there > aren't. If a service provider wants to allocate prefixes to customers > that aren't connected, they will need a larger block than the one that > allocates dynamically based on connected status. IMO, there are two problems (neither are critical, but rather nasty): - /29 is the easy "RIR allocation" limit currently: if that won't be enough, there will be fragmentation: some sTLA's get more than one prefix. Note: at 80% HD ratio, this would only be enough for about 38K customers. - /48 is the easy "organization allocation" limit: consider a university/big organization like Nokia with /48: well enough for for its own infrastructure but completely inadequate for: - giving e.g. dial-in/DSL users a /48 (heh :-) - giving e.g. dial-in/DSL users a /64 (at 80% HD ratio, about 7K users could be supported) ==> also fragmentation.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 3 06:12:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13EC82Q000405 for ; Sun, 3 Feb 2002 06:12:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g13EC8lY000404 for ipng-dist; Sun, 3 Feb 2002 06:12:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13EC52Q000397 for ; Sun, 3 Feb 2002 06:12:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06443 for ; Sun, 3 Feb 2002 06:12:20 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29930 for ; Sun, 3 Feb 2002 06:12:18 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09444; Sun, 3 Feb 2002 15:12:14 +0100 Received: from gsine05.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36124 from ; Sun, 3 Feb 2002 15:12:10 +0100 Message-Id: <3C5D1C84.FCAFDE0D@hursley.ibm.com> Date: Sun, 03 Feb 2002 12:18:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michel Py Cc: Philip Homburg , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > Modem users will be more than happy with a /64, because they do not need > to > subnet. If one wants to share the modem connection for their home > network, > that home network is a single subnet and will do fine with a /64. > Broadband > home connections (cable/dsl) would do ok with a /64, too, for the same > reason. > > Why would someone want a /68 (or whatever) for the living room, a /68 > for > the john, a /68 for the kitchen, a /68 for the garage? > Count the light bulbs and electric motors in your house. I don't want to exclude *anything* for the future. Luxury cars already contain several CAN subnets. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 3 06:55:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13EtY2Q000548 for ; Sun, 3 Feb 2002 06:55:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g13EtYdh000547 for ipng-dist; Sun, 3 Feb 2002 06:55:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13EtV2Q000540 for ; Sun, 3 Feb 2002 06:55:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20185 for ; Sun, 3 Feb 2002 06:55:47 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16044 for ; Sun, 3 Feb 2002 07:55:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g13EtW310813; Sun, 3 Feb 2002 15:55:32 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA12570; Sun, 3 Feb 2002 15:55:32 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g13EtVg58450; Sun, 3 Feb 2002 15:55:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202031455.g13EtVg58450@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: murugankat@future.futsoft.com cc: ipng@sunroof.eng.sun.com Subject: Re: ND - Neighbor Adv - 'O' Flag - clarification In-reply-to: Your message of Sat, 02 Feb 2002 15:20:35 +0530. <000101c1abcf$106ddd20$0906140a@future.futsoft.com> Date: Sun, 03 Feb 2002 15:55:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As per ND specification the Neighbor Advertisement message contains "O" Flag (OverRide flag). => the "O" flag is mainly about the link-layer address. What is the purpose of this flag. => this flag says if the cached link-layer address should be overrided by a new one or not. Or when the nodes is supposed set this Flag. => always when not in the following cases. Or when the nodes are not supposed to set this flag. => when the responder acts as a proxy or for an anycast address, i.e. when there can be more than one valid responder. The RFC 2461 has an explicit SHOULD/SHOULD NOT in the definition of the flag. I suppose whenever the receiver finds a difference between the sent link address and the address what it has in its ND cache it can modify the value. => no, look at the state machine in appendix. You should not do what you'd like (so there are some MUSTs) because ND should be determinitisc. Why is this extra bit...? => to provide advertisements for proxies/anycasts in a deterministic way. Please reread RFC 2461, this part is pretty clear! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 3 11:45:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13JjR2Q001299 for ; Sun, 3 Feb 2002 11:45:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g13JjR22001298 for ipng-dist; Sun, 3 Feb 2002 11:45:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13JjO2Q001291 for ; Sun, 3 Feb 2002 11:45:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23200 for ; Sun, 3 Feb 2002 11:45:38 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA04909 for ; Sun, 3 Feb 2002 12:45:37 -0700 (MST) Received: (qmail 30939 invoked from network); 3 Feb 2002 19:45:31 -0000 Received: from p508049a6.dip.t-dialin.net (HELO worker.muc.bieringer.de) (80.128.73.166) by mail.bieringer.de with SMTP; 3 Feb 2002 19:45:31 -0000 Date: Sun, 03 Feb 2002 20:45:30 +0100 From: Peter Bieringer To: Brian E Carpenter , Michel Py cc: Philip Homburg , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-ID: <47560000.1012765530@localhost> In-Reply-To: <3C5D1C84.FCAFDE0D@hursley.ibm.com> References: <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill- py.sacramento.ca.us> <3C5D1C84.FCAFDE0D@hursley.ibm.com> X-Mailer: Mulberry/2.2.0b1 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Sunday, February 03, 2002 12:18:28 PM +0100 Brian E Carpenter wrote: > Count the light bulbs and electric motors in your house. I don't > want to exclude *anything* for the future. Luxury cars already > contain several CAN subnets. Bridging can solve the problem and it's cheaper than routing. Perhaps a cost reduce factor. BTW: firewalling can be done also in a intelligent bridge. Afaik there is already such a project going on connecting Linux bridging with netfilter. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 4 00:19:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g148Jm2Q001989 for ; Mon, 4 Feb 2002 00:19:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g148JmFa001988 for ipng-dist; Mon, 4 Feb 2002 00:19:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g148Ji2Q001981 for ; Mon, 4 Feb 2002 00:19:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09912 for ; Mon, 4 Feb 2002 00:19:58 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05307 for ; Mon, 4 Feb 2002 01:19:57 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA12500; Mon, 4 Feb 2002 09:19:55 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29560 from ; Mon, 4 Feb 2002 09:19:51 +0100 Message-Id: <3C5E4426.7D9C4CC7@hursley.ibm.com> Date: Mon, 04 Feb 2002 09:19:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Peter Bieringer Cc: Michel Py , Philip Homburg , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill- py.sacramento.ca.us> <3C5D1C84.FCAFDE0D@hursley.ibm.com> <47560000.1012765530@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Being a victim of the bridging wars from ten or fifteen years ago, I can assure you that bridging is a lousy solution and not the one we should use as a strategy. What we learned then, people will relearn now. Brian Peter Bieringer wrote: > > --On Sunday, February 03, 2002 12:18:28 PM +0100 Brian E Carpenter > wrote: > > > Count the light bulbs and electric motors in your house. I don't > > want to exclude *anything* for the future. Luxury cars already > > contain several CAN subnets. > > Bridging can solve the problem and it's cheaper than routing. > Perhaps a cost reduce factor. > > BTW: firewalling can be done also in a intelligent bridge. Afaik > there is already such a project going on connecting Linux bridging > with netfilter. > > Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 4 00:23:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g148N52Q002018 for ; Mon, 4 Feb 2002 00:23:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g148N4p9002017 for ipng-dist; Mon, 4 Feb 2002 00:23:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g148N12Q002010 for ; Mon, 4 Feb 2002 00:23:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17219 for ; Mon, 4 Feb 2002 00:23:15 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04961 for ; Mon, 4 Feb 2002 00:23:10 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g148HVu01291; Mon, 4 Feb 2002 15:17:36 +0700 (ICT) From: Robert Elz To: Peter Bieringer cc: Brian E Carpenter , Michel Py , Philip Homburg , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: <47560000.1012765530@localhost> References: <47560000.1012765530@localhost> <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill- py.sacramento.ca.us> <3C5D1C84.FCAFDE0D@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Feb 2002 15:17:31 +0700 Message-ID: <1289.1012810651@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 03 Feb 2002 20:45:30 +0100 From: Peter Bieringer Message-ID: <47560000.1012765530@localhost> | Bridging can solve the problem and it's cheaper than routing. | Perhaps a cost reduce factor. Bridging isn't always possible - bridging only works amongst compatible link level technologies. Please, can we stop telling people how they have to run their nets, and get back to implementing the fullest possible flexibility, so they can choose, and we (the internet) isn't locked out of new technologies that might arise. I am not entirely sure how this question switched from what (if any) knowledge of address boundaries should be in implementations, to what size allocations ISPs should make (the two are just about unrelated), but all the recent discussions are just repeating the same old stuff over and over, with no sign that a different conclusion will be reached than it has been every time in the past. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 4 08:48:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Gme2Q002681 for ; Mon, 4 Feb 2002 08:48:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14GmdOr002680 for ipng-dist; Mon, 4 Feb 2002 08:48:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Gma2Q002673 for ; Mon, 4 Feb 2002 08:48:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06760 for ; Mon, 4 Feb 2002 08:48:51 -0800 (PST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16515 for ; Mon, 4 Feb 2002 09:48:51 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id CD233855 for ; Mon, 4 Feb 2002 08:52:24 -0800 (PST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id DC118152F for ; Mon, 4 Feb 2002 10:48:44 -0600 (CST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g14GmXM29562; Mon, 4 Feb 2002 11:48:33 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id LAA0000038922; Mon, 4 Feb 2002 11:48:43 -0500 (EST) Message-ID: <3C5EBB6B.32F000E8@zk3.dec.com> Date: Mon, 04 Feb 2002 11:48:43 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: IPNG Working Group Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" References: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> <4.3.2.7.2.20020124165004.024155b8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello I apologize for the very late mail as I finally found the time to go through this spec, but I have a few comments about Draft 4. Section 11.2 [page 46] > ... > When the data size is larger than the MTU of the outgoing interface, > the packet will be discarded. Applications can know the result by > enabling the IPV6_RECVPATHMTU option described below and receiving > the corresponding ancillary data items. Since, in this case, we instantly know that the packet is dropped, wouldn't it be better to specifically notify the application via a returned error code? Particularly, in the case of traceroute that you mention in this section, adding error code would be a good indication because traceroute does not try to receive on it's sending socket. This also applies to any other application that has a sending and a receiving socket. An error code would tell the application that it should perform a receive operation to learn the mtu. Section 11.3 [page 46] > ... > When the application is sending packets too big for the path MTU > recvmsg() will return zero (indicating no data) but there will be a > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will > indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long. What happens to any buffered data? If there is buffered data that came before the MTU error, should recvmsg() still return 0 and no data? > This cmsghdr will be passed to every socket that sets the > IPV6_RECVPATHMTU socket option, even if the socket is non-connected. > Note that this also means an application that sets the option may get > the ancillary data upon a too big message sent from other > applications to the same destination. Actually, it's worse then that. For non-connected sockets (I am assuming non-connected means no destination address specified), the ancillary data will be given to all of them. This now places a burden on the application to figure out whether they are sending to a given destination or not. We ether need a warning here that the application may receive MTU ancillary data for a destination they do not care about, or we may want to restrict this to connected sockets only (i.e. the ones with destination address set). Section 11.4 [page 47] > This specification defines a get-only socket option to retrieve the > current path MTU value for the destination of a given connected > socket. > ... > This option can only be used for a connected socket, because a non- > connected socket does not have the information of the destination and > there is no way to pass the destination via getsockopt(). When > getsockopt() for this option is issued on a non-connected socket, the > call will fail. Why limit this functionality to only a connected socket? Is it because of the odd semantics with providing data to a getsockopt? I mean, the application could set the ip6m_addr to the destination address it wants to look up the MTU for, but it would be a little strange for an application to specify data on a getsockopt(). Section 14.2 and 14.3 [pages 51 and 52] It may be worth mentioning that AF_UNSPEC may also be used as an argument to rcmd_af and rexec_af for protocol independent applications. This aligns this API closer to the basic api. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 4 12:40:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Ke12Q003195 for ; Mon, 4 Feb 2002 12:40:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14Ke0EA003194 for ipng-dist; Mon, 4 Feb 2002 12:40:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Kdu2Q003187 for ; Mon, 4 Feb 2002 12:39:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22911 for ; Mon, 4 Feb 2002 12:40:01 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23628 for ; Mon, 4 Feb 2002 13:40:00 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Feb 2002 12:39:58 -0800 From: "Tony Hain" To: "Antonio Querubin" Cc: "Peter Bieringer" , "Philip Homburg" , Subject: RE: IPv6 Addr/Prefix clarification Date: Mon, 4 Feb 2002 12:39:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Antonio Querubin wrote: > On Sat, 2 Feb 2002, Antonio Querubin wrote: > > > I suspect the practice of assigning a /48 for every complex layer-3 > > network isn't scalable for many medium and large service > providers. The > > number of service providers with more than 65536 clients or > customers is > ^^^^^ > > Oops! What am I thinking? Change that to 8192 as we're > really butting up > against the size of the space between /35 and /48, Reality is probably > somewhere between 8192 and 65536. > Reality is that any provider with customers will get more than a /35, that is only the starting point and even that number is likely to change. If a provider doesn't allocate a /48 to its customers with complex networks, the customers will simply tunnel over them because they already have a /48 by using 6to4. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 4 18:31:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g152Va2Q003814 for ; Mon, 4 Feb 2002 18:31:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g152Vaen003813 for ipng-dist; Mon, 4 Feb 2002 18:31:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g152VX2Q003806; Mon, 4 Feb 2002 18:31:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21515; Mon, 4 Feb 2002 18:31:49 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17741; Mon, 4 Feb 2002 19:31:49 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id TAA04322; Mon, 4 Feb 2002 19:31:48 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA03575; Mon, 4 Feb 2002 19:31:48 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 4 Feb 2002 20:31:48 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'Pekka Nikander'" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com Cc: "Charles E. Perkins" Subject: RE: [Monet] The semantics of the Routing Header? Date: Mon, 4 Feb 2002 20:31:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, In IPv6, the mobile node builds a Care-of-Address from Router Advertisements received on the visited network and uses it as a temporary, topologically correct, IPv6 address. When he moves, he gets another Care-of-Address - he always keep the Home Address, and all other nodes that communicate with him use the Home Address to identify him, except when they are capable of Route Optimization. It is in Route Optimization that the communicating node uses the Routing Header to build what looks identical to a Source Route option, with the Care-of-Address being the first entry in the source route, and the Home Address being the second - and final - entry of the source route. It is a special case of Source Route, since both addresses in the list are "being used" by the same node. Perhaps it should have been a separate option for all the confusion that it is apparently generating, but when it was conceived it must have seemed like a good thing - a way to conserve IPv6 option code points perhaps? Cyndi >The reason why I am asking this is the scenario, which >Charlie Perkins has offered, where a packet is source >routed through a Mobile Node that is away from home. >According to his argumentation, in such case the >routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > >where the Care-of-Address is the current location of >the mobile node, and the Home Address is more like >the end-point identifier of the mobile node. I am >having hard time in clearly crasping the intended >semantic meaning of this construction. > >--Pekka Nikander _______________________________________________ Monet mailing list Monet@thorgal.crm.mot.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 01:44:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159iF2Q004692 for ; Tue, 5 Feb 2002 01:44:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g159iE57004689 for ipng-dist; Tue, 5 Feb 2002 01:44:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159hw2Q004653 for ; Tue, 5 Feb 2002 01:43:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g159i9M11085; Tue, 5 Feb 2002 10:44:09 +0100 (MET) Date: Tue, 5 Feb 2002 10:04:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND - Neighbor Adv - 'O' Flag - clarification To: murugankat@future.futsoft.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <000101c1abcf$106ddd20$0906140a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As per ND specification the Neighbor Advertisement message contains "O" > Flag (OverRide flag). > What is the purpose of this flag. Or when the nodes is supposed set this > Flag. Or when the nodes are not supposed to set this flag. The mechanical aspects of when it is set are covered in RFC 2460. > I suppose whenever the receiver finds a difference between the sent link > address and the address what it has in its ND cache it can modify the value. Correct. That is what RFC 2460 says. In addition there is some effect on the reachability state as specified in the rfc. > Why is this extra bit...? That question I don't think is clearly answered in the RFC. The motivation is that there are two possible approaches for dealing with information such as the link-layer address received in a ND packet: 1. The last received information takes precedence 2. The first received information takes precedence Normally #1 makes sense - the link layer address might change e.g. due to a replacement of the network adaptor or some form of failover between multiple adapters. But in the case of a neighbor solicitation #2 makes more sense - it is desirable by default to pick the first entity to respond since there is some correlation between the speed to respond and the load and/or speed of the node. Also, in the case of proxy neighbor advertisements it might make sense to make the precedence be determined by the sender of the NA. In the case of Mobile IP there is a home agent that proxies for a mobile node that is away from home. But in the case when the mobile moves home and start sending NA messages you'd like those message to take precedence over any proxy advertisements sent by the HA. (Of course the HA will be notified by the MN to stop sending the proxy advertisement but before it does the above rule makes sense.) The single override bit provides the flexibility to do all of the above. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 01:44:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159iE2Q004688 for ; Tue, 5 Feb 2002 01:44:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g159iDwA004686 for ipng-dist; Tue, 5 Feb 2002 01:44:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159hw2Q004652 for ; Tue, 5 Feb 2002 01:43:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g159iAM11091; Tue, 5 Feb 2002 10:44:10 +0100 (MET) Date: Tue, 5 Feb 2002 10:23:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" To: Vladislav Yasevich Cc: IPNG Working Group In-Reply-To: "Your message with ID" <3C5EBB6B.32F000E8@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Since, in this case, we instantly know that the packet is dropped, wouldn't > it be better to specifically notify the application via a returned error > code? The X/Open (or whoever "owns" the socket standard now adays) socket specifications allow for implementations where certain error messages, such as EHOSTUNREACH etc, can not be returned as an error to a send/sendto/sendmsg. Implementations using asynchronous message passing between the socket layer and the procol stack depend on this being allowable behavior. So I don't think it would be useful to have the IPv6 socket API extensions pretend that such implementations exist and indeed conform to the socket API standards. > > When the application is sending packets too big for the path MTU > > recvmsg() will return zero (indicating no data) but there will be a > > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will > > indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long. > > What happens to any buffered data? If there is buffered data that came > before the MTU error, should recvmsg() still return 0 and no data? The assumption is that the mtu indication is a separate "event" ("record" for those looking a *BSD socket code) thus in this case the application would first receive the buffered data and then receive the msg with no data and just msg_control. > Actually, it's worse then that. For non-connected sockets (I am assuming > non-connected > means no destination address specified), the ancillary data will be given to > all of them. > This now places a burden on the application to figure out whether they are > sending to a > given destination or not. We ether need a warning here that the application > may > receive MTU ancillary data for a destination they do not care about, or we > may want to > restrict this to connected sockets only (i.e. the ones with destination > address set). The purpose of the ancillary data item is to allow applications which do not connect() their UDP sockets to correctly participate in path MTU discovery. So I think it makes sense to put in some explicit text saying that the application needs to verify that it indeed has sent a packet to the desination. However, in practise I don't see this being an issue. A UDP application participating in path MTU discovery (i.e. any UDP application which wishes to send packet larger than 1280 bytes) must maintain path mtu state for all the peers it is sending data to. So receiving the IPV6_PATHMTU, just means it need to find that state and update it. > Why limit this functionality to only a connected socket? Is it because > of the odd semantics with providing data to a getsockopt? I mean, the > application > could set the ip6m_addr to the destination address it wants to look up the > MTU for, > but it would be a little strange for an application to specify data on a > getsockopt(). s/a little strange/completely inconsistent with getsockopt as defined/ One could envision being able to ask questions about destination addresses where path MTU is one of the things to ask. But this quickly evolves into being able to ask about other useful things (cached rtt estimate, etc). I belive RTM_GET with routing sockets already provides an API for asking all those questions. Would it be useful to add a pointer to routing sockets in the spec? > Section 14.2 and 14.3 [pages 51 and 52] > > It may be worth mentioning that AF_UNSPEC may also be used as an argument to > rcmd_af and rexec_af for protocol independent applications. This aligns this > API closer to the basic api. OK Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 02:15:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFO2Q004943 for ; Tue, 5 Feb 2002 02:15:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFOj4004942 for ipng-dist; Tue, 5 Feb 2002 02:15:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFG2Q004929 for ; Tue, 5 Feb 2002 02:15:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05384 for ; Tue, 5 Feb 2002 02:15:31 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08238 for ; Tue, 5 Feb 2002 03:15:30 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g15AFTX4028655 for ; Tue, 5 Feb 2002 11:15:29 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Feb 05 11:15:14 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:15:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D55A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , Bob Hinden Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Date: Tue, 5 Feb 2002 11:14:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can't find Bob's original email ! So I'll respond to this part. > On Thu, 31 Jan 2002, Bob Hinden wrote: > > Another approach is add text to make it clear that when > there are multiple > > administrative domains involved that the preferences can > only be compared > > it they are being set in the same manner. => In theory that is feasible, but let's consider the basic problem: One domain is advertising to one or more hosts. The router has no clue which other domains this host is connected to. So (especially on shared media) there is no way that a generic RA can do this. Unless the RA includes all domain identities that it has agreements with... just too hard. I can't imagine domain admins organising meetings to decide on how they would set the preference values :) I think we should just add text to say that this value can not be compared when received from different administrative domains. I don't think > there is any > > simple automatic way of doing this (and I think we would > want to avoid some > > sort of policy certificates....). => Agreed. > > > > This is probably another reason why only a few preference > values are needed. => The only difference I see between having a small range of values vs a large range is that a large range would give better granularity. Either way, the draft should really give some rough guidlines on what each preference means. Even if they're not used across different domains. Pekka wrote: > > Well, it would be possible chop off a few more reserved > bits (e.g. 2), and > make this "domain of applicability" preference: two > preferences would only > be valid inside the same "domain" class. > > But this relies on the advertising parties making this right.. and > otherwise sounds like a bad (==unnecessary) idea too. => eeehh, yeah I agree it's unnecessay. For hosts to decide to route their traffic through a different domain or do some load balancing we need a lot more than what the draft currently specifies, just KISS. Hesham PS: I'm obviously thinking of a mobile host that might have several differnt flows and would like to route these flows through the right access, depending on the characteristics of this access. This draft is more relevant to a dedicated server (e.g. HTTP) that needs to load balance traffic between two links. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 05:14:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15DE62Q005772 for ; Tue, 5 Feb 2002 05:14:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15DE6pR005771 for ipng-dist; Tue, 5 Feb 2002 05:14:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15DE32Q005764 for ; Tue, 5 Feb 2002 05:14:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13286 for ; Tue, 5 Feb 2002 05:14:18 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19533 for ; Tue, 5 Feb 2002 05:14:17 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA22654 for ; Tue, 5 Feb 2002 06:14:16 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA24382 for ; Tue, 5 Feb 2002 06:03:04 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 5 Feb 2002 07:14:15 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B00DC2EC83 for ; Tue, 5 Feb 2002 14:09:36 +0100 (CET) To: ipng@sunroof.eng.sun.com Subject: Randomness and uniqueness From: Alexandru Petrescu Date: 05 Feb 2002 14:14:09 +0100 Message-Id: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, there's currently a stream of proposals that put random bits on the Interface ID of an IPv6 address. A background assumption is that the length of the Interface ID is 64 bits. Another assumption is that since those ID's are generated from random sources, then their uniqueness is guaranteed for practical purposes. May I point out the following: -mathematical uniqueness is not guaranteed, there's already an acknowledged collision probability. -to this probability one should add "administrative probability" where same prefixes are accidentally assigned to two entities. -add implementation error probabilities, where a widespread implementation uses a weak algorithm to generate that random numbers, for example use as input time of day or the birth date, or short passphrases, etc. -add the p in prf. The last three factors are very hard to quantify, and as such the overall probability of collision events also seems to me very hard to quantify. Just a thought, born out of contemplating randomness. What do you think? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 05:54:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dsm2Q006076 for ; Tue, 5 Feb 2002 05:54:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15DslJj006075 for ipng-dist; Tue, 5 Feb 2002 05:54:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dsh2Q006068 for ; Tue, 5 Feb 2002 05:54:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11469 for ; Tue, 5 Feb 2002 05:54:59 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03024 for ; Tue, 5 Feb 2002 06:54:57 -0700 (MST) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g15Dsp359124; Tue, 5 Feb 2002 22:54:51 +0900 (JST) Date: Tue, 05 Feb 2002 22:54:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: IPNG Working Group Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: References: <3C5EBB6B.32F000E8@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 116 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Vlad for the careful reading, and thanks Erik for the quick response. >>>>> On Tue, 5 Feb 2002 10:23:24 +0100 (CET), >>>>> Erik Nordmark said: >> Since, in this case, we instantly know that the packet is dropped, wouldn't >> it be better to specifically notify the application via a returned error >> code? > The X/Open (or whoever "owns" the socket standard now adays) socket > specifications allow for implementations where certain error > messages, such as EHOSTUNREACH etc, can not be returned as an > error to a send/sendto/sendmsg. > Implementations using asynchronous message passing between the socket layer > and the procol stack depend on this being allowable behavior. That's exactly the reason why the specification does not define an error code in this case. If necessary, I'll put some additional note on this to Section 11.2, but it will still not specify a particular error code. >> > When the application is sending packets too big for the path MTU >> > recvmsg() will return zero (indicating no data) but there will be a >> > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will >> > indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long. >> >> What happens to any buffered data? If there is buffered data that came >> before the MTU error, should recvmsg() still return 0 and no data? > The assumption is that the mtu indication is a separate "event" > ("record" for those looking a *BSD socket code) thus in this case > the application would first receive the buffered data and then receive > the msg with no data and just msg_control. That's the same as my intention, and our implementation in fact acts as above (i.e. the app first receives the buffered data). The comment is reasonable, so I'll clarify this explicitly. >> Actually, it's worse then that. For non-connected sockets (I am assuming >> non-connected >> means no destination address specified), the ancillary data will be given to >> all of them. >> This now places a burden on the application to figure out whether they are >> sending to a >> given destination or not. We ether need a warning here that the application >> may >> receive MTU ancillary data for a destination they do not care about, or we >> may want to >> restrict this to connected sockets only (i.e. the ones with destination >> address set). > The purpose of the ancillary data item is to allow applications which do > not connect() their UDP sockets to correctly participate in path MTU > discovery. > So I think it makes sense to put in some explicit text saying that the > application needs to verify that it indeed has sent a packet to the > desination. OK. > However, in practise I don't see this being an issue. A UDP application > participating in path MTU discovery (i.e. any UDP application which wishes > to send packet larger than 1280 bytes) must maintain path mtu state for > all the peers it is sending data to. So receiving the IPV6_PATHMTU, > just means it need to find that state and update it. I agree, and, please also note that IPV6_RECVPATHMTU is disabled by default. Thus, almost all applications would not receive the noisy ancillary data. >> Why limit this functionality to only a connected socket? Is it because >> of the odd semantics with providing data to a getsockopt? I mean, the >> application >> could set the ip6m_addr to the destination address it wants to look up the >> MTU for, >> but it would be a little strange for an application to specify data on a >> getsockopt(). > s/a little strange/completely inconsistent with getsockopt as defined/ > One could envision being able to ask questions about destination addresses > where path MTU is one of the things to ask. > But this quickly evolves into being able to ask about other useful things > (cached rtt estimate, etc). I belive RTM_GET with routing sockets already > provides an API for asking all those questions. > Would it be useful to add a pointer to routing sockets in the spec? Hmm, it's okay with me, but, we may even have to remove the section and just mention the possibility of the more generic mechanism. Do we really have to need the specific interface (i.e. IPV6_PATHMTU)? (If there's no strong opinion, my default take will be to keep the current spec with some note on the general interface.) >> Section 14.2 and 14.3 [pages 51 and 52] >> >> It may be worth mentioning that AF_UNSPEC may also be used as an argument to >> rcmd_af and rexec_af for protocol independent applications. This aligns this >> API closer to the basic api. > OK Okay with me, too. Actually, our implementation of rcmd_af() has already supported the case of AF_UNSPEC. I'll soon revise the draft with taking all into account. If anyone of you has further comments, please make them here. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 06:28:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15ESl2Q006422 for ; Tue, 5 Feb 2002 06:28:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15ESlXt006421 for ipng-dist; Tue, 5 Feb 2002 06:28:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15ESh2Q006414 for ; Tue, 5 Feb 2002 06:28:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11749 for ; Tue, 5 Feb 2002 06:28:58 -0800 (PST) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19739 for ; Tue, 5 Feb 2002 06:28:55 -0800 (PST) Received: from exchange2.zdv.Uni-Mainz.DE (exchange2.zdv.Uni-Mainz.DE [134.93.8.113]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g15ESZl18978; Tue, 5 Feb 2002 15:28:35 +0100 (MET) Received: from exstore1.zdv.uni-mainz.de ([134.93.8.124]) by exchange2.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 15:23:50 +0100 Received: from mail pickup service by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC; Tue, 5 Feb 2002 15:23:38 +0100 Received: from mailgate1.zdv.Uni-Mainz.DE ([134.93.8.56]) by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 11:18:18 +0100 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g15AIHe18918 for ; Tue, 5 Feb 2002 11:18:17 +0100 (MET) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26853; Tue, 5 Feb 2002 03:17:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05858; Tue, 5 Feb 2002 02:17:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFO2Q004943 for ; Tue, 5 Feb 2002 02:15:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFOj4004942 for ipng-dist; Tue, 5 Feb 2002 02:15:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFG2Q004929 for ; Tue, 5 Feb 2002 02:15:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05384 for ; Tue, 5 Feb 2002 02:15:31 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08238 for ; Tue, 5 Feb 2002 03:15:30 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g15AFTX4028655 for ; Tue, 5 Feb 2002 11:15:29 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Feb 05 11:15:14 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:15:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D55A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , Bob Hinden Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Comments to date on "IPv6 Host to Router Load Sharing" Date: Tue, 5 Feb 2002 11:14:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Feb 2002 10:18:18.0325 (UTC) FILETIME=[6E2CE850:01C1AE2E] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can't find Bob's original email ! So I'll respond to this part. > On Thu, 31 Jan 2002, Bob Hinden wrote: > > Another approach is add text to make it clear that when > there are multiple > > administrative domains involved that the preferences can > only be compared > > it they are being set in the same manner. => In theory that is feasible, but let's consider the basic problem: One domain is advertising to one or more hosts. The router has no clue which other domains this host is connected to. So (especially on shared media) there is no way that a generic RA can do this. Unless the RA includes all domain identities that it has agreements with... just too hard. I can't imagine domain admins organising meetings to decide on how they would set the preference values :) I think we should just add text to say that this value can not be compared when received from different administrative domains. I don't think > there is any > > simple automatic way of doing this (and I think we would > want to avoid some > > sort of policy certificates....). => Agreed. > > > > This is probably another reason why only a few preference > values are needed. => The only difference I see between having a small range of values vs a large range is that a large range would give better granularity. Either way, the draft should really give some rough guidlines on what each preference means. Even if they're not used across different domains. Pekka wrote: > > Well, it would be possible chop off a few more reserved > bits (e.g. 2), and > make this "domain of applicability" preference: two > preferences would only > be valid inside the same "domain" class. > > But this relies on the advertising parties making this right.. and > otherwise sounds like a bad (==unnecessary) idea too. => eeehh, yeah I agree it's unnecessay. For hosts to decide to route their traffic through a different domain or do some load balancing we need a lot more than what the draft currently specifies, just KISS. Hesham PS: I'm obviously thinking of a mobile host that might have several differnt flows and would like to route these flows through the right access, depending on the characteristics of this access. This draft is more relevant to a dedicated server (e.g. HTTP) that needs to load balance traffic between two links. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 06:36:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Eap2Q007525 for ; Tue, 5 Feb 2002 06:36:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15EapmK007524 for ipng-dist; Tue, 5 Feb 2002 06:36:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Eak2Q007517 for ; Tue, 5 Feb 2002 06:36:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20450 for ; Tue, 5 Feb 2002 06:37:01 -0800 (PST) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29125 for ; Tue, 5 Feb 2002 07:37:00 -0700 (MST) Received: from exchange2.zdv.Uni-Mainz.DE (exchange2.zdv.Uni-Mainz.DE [134.93.8.113]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g15EWhh12209; Tue, 5 Feb 2002 15:32:43 +0100 (MET) Received: from exstore1.zdv.uni-mainz.de ([134.93.8.124]) by exchange2.zdv.Uni-Mainz.DE with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 15:26:09 +0100 Received: from mail pickup service by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC; Tue, 5 Feb 2002 15:26:07 +0100 Received: from EXSTORE2.zdv.uni-mainz.de ([134.93.8.69]) by exstore1.zdv.uni-mainz.de with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 10:46:23 +0100 Received: from mailgate1.zdv.Uni-Mainz.DE ([134.93.8.56]) by EXSTORE2.zdv.uni-mainz.de with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 10:46:22 +0100 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id g159kLe14558 for ; Tue, 5 Feb 2002 10:46:22 +0100 (MET) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01402; Tue, 5 Feb 2002 01:45:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15507; Tue, 5 Feb 2002 01:45:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159iF2Q004692 for ; Tue, 5 Feb 2002 01:44:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g159iE57004689 for ipng-dist; Tue, 5 Feb 2002 01:44:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159hw2Q004653 for ; Tue, 5 Feb 2002 01:43:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g159i9M11085; Tue, 5 Feb 2002 10:44:09 +0100 (MET) Date: Tue, 5 Feb 2002 10:04:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND - Neighbor Adv - 'O' Flag - clarification To: murugankat@future.futsoft.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <000101c1abcf$106ddd20$0906140a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-OriginalArrivalTime: 05 Feb 2002 09:46:23.0238 (UTC) FILETIME=[F8B1D260:01C1AE29] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As per ND specification the Neighbor Advertisement message contains "O" > Flag (OverRide flag). > What is the purpose of this flag. Or when the nodes is supposed set this > Flag. Or when the nodes are not supposed to set this flag. The mechanical aspects of when it is set are covered in RFC 2460. > I suppose whenever the receiver finds a difference between the sent link > address and the address what it has in its ND cache it can modify the value. Correct. That is what RFC 2460 says. In addition there is some effect on the reachability state as specified in the rfc. > Why is this extra bit...? That question I don't think is clearly answered in the RFC. The motivation is that there are two possible approaches for dealing with information such as the link-layer address received in a ND packet: 1. The last received information takes precedence 2. The first received information takes precedence Normally #1 makes sense - the link layer address might change e.g. due to a replacement of the network adaptor or some form of failover between multiple adapters. But in the case of a neighbor solicitation #2 makes more sense - it is desirable by default to pick the first entity to respond since there is some correlation between the speed to respond and the load and/or speed of the node. Also, in the case of proxy neighbor advertisements it might make sense to make the precedence be determined by the sender of the NA. In the case of Mobile IP there is a home agent that proxies for a mobile node that is away from home. But in the case when the mobile moves home and start sending NA messages you'd like those message to take precedence over any proxy advertisements sent by the HA. (Of course the HA will be notified by the MN to stop sending the proxy advertisement but before it does the above rule makes sense.) The single override bit provides the flexibility to do all of the above. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 06:51:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EpP2Q008293 for ; Tue, 5 Feb 2002 06:51:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15EpPKt008292 for ipng-dist; Tue, 5 Feb 2002 06:51:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EpL2Q008285 for ; Tue, 5 Feb 2002 06:51:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23401 for ; Tue, 5 Feb 2002 06:51:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20817 for ; Tue, 5 Feb 2002 06:51:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01809; Tue, 5 Feb 2002 09:51:31 -0500 (EST) Message-Id: <200202051451.JAA01809@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt Date: Tue, 05 Feb 2002 09:51:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Note about the Use of IPv6 /127 Prefix Length Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-00.txt Pages : 3 Date : 04-Feb-02 In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-ipv6-127-prefixlen-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-ipv6-127-prefixlen-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020204134156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-ipv6-127-prefixlen-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-ipv6-127-prefixlen-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020204134156.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 10:01:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15I1n2Q009552 for ; Tue, 5 Feb 2002 10:01:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15I1nLV009551 for ipng-dist; Tue, 5 Feb 2002 10:01:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15I1k2Q009544 for ; Tue, 5 Feb 2002 10:01:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26214 for ; Tue, 5 Feb 2002 10:02:01 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10643 for ; Tue, 5 Feb 2002 10:02:01 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Feb 2002 10:01:07 -0800 From: "Tony Hain" To: "Alexandru Petrescu" , Subject: RE: Randomness and uniqueness Date: Tue, 5 Feb 2002 10:01:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As you point out uniqueness is not guaranteed, even for administrative assignments. That is why RFC 2462 specifically states: The Duplicate Address Detection algorithm is performed on all addresses, independent of whether they are obtained via stateless or stateful autoconfiguration. In a quick scan of 3041 I didn't see a reference to that, but it was a fundemental assumption. If 3041 is updated it would probably help to have a clear pointer back to 2462. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Alexandru Petrescu > Sent: Tuesday, February 05, 2002 5:14 AM > To: ipng@sunroof.eng.sun.com > Subject: Randomness and uniqueness > > > Hi, there's currently a stream of proposals that put random bits on > the Interface ID of an IPv6 address. A background assumption is that > the length of the Interface ID is 64 bits. Another assumption is that > since those ID's are generated from random sources, then their > uniqueness is guaranteed for practical purposes. > > May I point out the following: > > -mathematical uniqueness is not guaranteed, there's already an > acknowledged collision probability. > -to this probability one should add "administrative probability" where > same prefixes are accidentally assigned to two entities. > -add implementation error probabilities, where a widespread > implementation uses a weak algorithm to generate that random numbers, > for example use as input time of day or the birth date, or short > passphrases, etc. > -add the p in prf. > > The last three factors are very hard to quantify, and as such the > overall probability of collision events also seems to me very hard to > quantify. > > Just a thought, born out of contemplating randomness. What do you > think? > > Alex > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 10:31:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15IV02Q009695 for ; Tue, 5 Feb 2002 10:31:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15IV0hf009694 for ipng-dist; Tue, 5 Feb 2002 10:31:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15IUv2Q009687 for ; Tue, 5 Feb 2002 10:30:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04810 for ; Tue, 5 Feb 2002 10:31:13 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17747 for ; Tue, 5 Feb 2002 11:31:11 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA26566 for ; Tue, 5 Feb 2002 11:31:11 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA13593 for ; Tue, 5 Feb 2002 11:31:10 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 5 Feb 2002 12:31:03 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 83FBC2EC83; Tue, 5 Feb 2002 19:26:30 +0100 (CET) To: "Tony Hain" Cc: Subject: Re: Randomness and uniqueness References: From: Alexandru Petrescu Date: 05 Feb 2002 19:31:07 +0100 In-Reply-To: Message-Id: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" writes: > In a quick scan of 3041 I didn't see a reference to that, but it was a > fundemental assumption. If 3041 is updated it would probably help to > have a clear pointer back to 2462. Sure, thanks for pointing this. I wasn't referring to rfc3041 though. My remark was rather generic. For example, let's say I design DHCP2 where the 65th bit of all addresses has particular meaning to DHCP2 servers: helps in better authenticating clients. Also, the 66th bit up to 128th contain a random number that is used to securely communicate between DHCP2 servers and relays. Of course, this would have huge advantages for the DHCP2 protocol, since it allows combining trust properties into addressing and routing properties. But would this work with other things? Thanks for any feedback, Alex PS: with respect to uniqueness there's a draft on random Interface ID's without DAD: draft-soto-mobileip-random-iids-00.txt PPS: with respect to security there's ongoing discussion on Mobile IP, around a novel method to generate addresses (Computationally Generated Addresses). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 11:19:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JJL2Q009889 for ; Tue, 5 Feb 2002 11:19:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15JJLDX009888 for ipng-dist; Tue, 5 Feb 2002 11:19:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JJI2Q009881 for ; Tue, 5 Feb 2002 11:19:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10051 for ; Tue, 5 Feb 2002 11:19:32 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15088 for ; Tue, 5 Feb 2002 11:19:31 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Feb 2002 11:19:31 -0800 From: "Tony Hain" To: Cc: Subject: RE: Randomness and uniqueness Date: Tue, 5 Feb 2002 11:19:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A single bit for authentication seems like weak authentication... ;) At any rate, you can't use truly random values in addressing and expect to establish a trust based on that. At best you could have a pseudo-random table that both ends are working from, but either that table is well-known, or establishing it and maintaining synchronization will be an operational nightmare. As for using an address without performing DAD, this is a *bad idea* in general and fast-handoff is no excuse to avoid verifying that someone else is not already using an address on the link (assigned or random). If mip is that far off in the weeds we may need an AD to ask them to revisit their charter. Tony > -----Original Message----- > From: petrescu@crm.mot.com [mailto:petrescu@crm.mot.com] > Sent: Tuesday, February 05, 2002 10:31 AM > To: Tony Hain > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Randomness and uniqueness > > > "Tony Hain" writes: > > In a quick scan of 3041 I didn't see a reference to that, > but it was a > > fundemental assumption. If 3041 is updated it would probably help to > > have a clear pointer back to 2462. > > Sure, thanks for pointing this. I wasn't referring to rfc3041 > though. > > My remark was rather generic. > > For example, let's say I design DHCP2 where the 65th bit of all > addresses has particular meaning to DHCP2 servers: helps in better > authenticating clients. Also, the 66th bit up to 128th contain a > random number that is used to securely communicate between DHCP2 > servers and relays. > > Of course, this would have huge advantages for the DHCP2 protocol, > since it allows combining trust properties into addressing and routing > properties. But would this work with other things? > > Thanks for any feedback, > > Alex > > PS: with respect to uniqueness there's a draft on random Interface > ID's without DAD: draft-soto-mobileip-random-iids-00.txt > PPS: with respect to security there's ongoing discussion on Mobile IP, > around a novel method to generate addresses (Computationally > Generated Addresses). > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 11:31:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JVB2Q009958 for ; Tue, 5 Feb 2002 11:31:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15JVB5J009957 for ipng-dist; Tue, 5 Feb 2002 11:31:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JV52Q009950 for ; Tue, 5 Feb 2002 11:31:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21253 for ; Tue, 5 Feb 2002 11:31:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19958 for ; Tue, 5 Feb 2002 11:31:19 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24777; Tue, 5 Feb 2002 11:31:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g15JVIM26948; Tue, 5 Feb 2002 11:31:18 -0800 X-mProtect:  Tue, 5 Feb 2002 11:31:18 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkdL2F3; Tue, 05 Feb 2002 11:31:16 PST Message-ID: <3C603304.F7D98186@iprg.nokia.com> Date: Tue, 05 Feb 2002 11:31:16 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Hain CC: petrescu@crm.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > A single bit for authentication seems like weak authentication... ;) > > At any rate, you can't use truly random values in addressing and expect > to establish a trust based on that. At best you could have a > pseudo-random table that both ends are working from, but either that > table is well-known, or establishing it and maintaining synchronization > will be an operational nightmare. > > As for using an address without performing DAD, this is a *bad idea* in > general and fast-handoff is no excuse to avoid verifying that someone > else is not already using an address on the link (assigned or random). > If mip is that far off in the weeds we may need an AD to ask them to > revisit their charter. two comments. These are individual proposals in the Mobile IP WG. and these people are being "encouraged" to take them up in the IPv6 WG rather than the Mobile IP WG. and Fast Handoffs for Mobile IPv6 does not say "dont do DAD". Vijay > > Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 11:48:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JmQ2Q010194 for ; Tue, 5 Feb 2002 11:48:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15JmQcF010193 for ipng-dist; Tue, 5 Feb 2002 11:48:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JmN2Q010186 for ; Tue, 5 Feb 2002 11:48:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02168 for ; Tue, 5 Feb 2002 11:48:37 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22698 for ; Tue, 5 Feb 2002 12:48:36 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA21685 for ; Tue, 5 Feb 2002 12:48:36 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA02704 for ; Tue, 5 Feb 2002 12:48:35 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Tue, 5 Feb 2002 13:48:28 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E0AA22EC83; Tue, 5 Feb 2002 20:43:55 +0100 (CET) To: "Tony Hain" Cc: Subject: Re: Randomness and uniqueness References: From: Alexandru Petrescu Date: 05 Feb 2002 20:48:32 +0100 In-Reply-To: Message-Id: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" writes: > As for using an address without performing DAD, this is a *bad idea* in > general and fast-handoff is no excuse to avoid verifying that someone > else is not already using an address on the link (assigned or random). > If mip is that far off in the weeds we may need an AD to ask them to > revisit their charter. Sorry, my remark was generally about how to put bits in addresses. The DAD thing is another topic, not discussed in Mobile IP, not a WG item. But your remark is valuable advice, helps for better understanding where things go. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 11:50:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Jov2Q010217 for ; Tue, 5 Feb 2002 11:50:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15Jov7F010216 for ipng-dist; Tue, 5 Feb 2002 11:50:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Jos2Q010209 for ; Tue, 5 Feb 2002 11:50:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25897 for ; Tue, 5 Feb 2002 11:51:08 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27393 for ; Tue, 5 Feb 2002 11:51:08 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Feb 2002 11:51:07 -0800 From: "Tony Hain" To: "Vijay Devarapalli" Cc: , Subject: RE: Randomness and uniqueness Date: Tue, 5 Feb 2002 11:51:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C603304.F7D98186@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay Devarapalli wrote: > two comments. > > These are individual proposals in the Mobile IP WG. and these > people are being "encouraged" to take them up in the IPv6 WG > rather than the Mobile IP WG. I understand the role of cross WG sanity checking, but usually that is only done when the origin WG believes in the work but want verification, or that the work really belongs in the other group. > > and Fast Handoffs for Mobile IPv6 does not say "dont do DAD". > The document referenced specifically tries to justify avoiding DAD because it takes too long for fast handoffs. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 11:59:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Jxb2Q010367 for ; Tue, 5 Feb 2002 11:59:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15Jxb8g010366 for ipng-dist; Tue, 5 Feb 2002 11:59:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JxY2Q010359 for ; Tue, 5 Feb 2002 11:59:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25713 for ; Tue, 5 Feb 2002 11:59:48 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15403 for ; Tue, 5 Feb 2002 12:59:48 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA03732 for ; Tue, 5 Feb 2002 12:59:48 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA00797 for ; Tue, 5 Feb 2002 12:59:48 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 5 Feb 2002 12:59:46 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D4E8D2EC83; Tue, 5 Feb 2002 20:55:07 +0100 (CET) To: "Tony Hain" Cc: "Vijay Devarapalli" , Subject: Re: Randomness and uniqueness References: From: Alexandru Petrescu Date: 05 Feb 2002 20:59:44 +0100 In-Reply-To: Message-Id: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" writes: > I understand the role of cross WG sanity checking, but usually that is > only done when the origin WG believes in the work but want verification, > or that the work really belongs in the other group. Hi, the remark was born out mainly from my personal oppinions and views on certain issues. I do not intend to boil any ocean. I'm trying to find out some guidance on how one could put bits into addresses. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 12:09:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15K992Q010517 for ; Tue, 5 Feb 2002 12:09:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15K9949010516 for ipng-dist; Tue, 5 Feb 2002 12:09:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15K962Q010508 for ; Tue, 5 Feb 2002 12:09:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00305 for ; Tue, 5 Feb 2002 12:09:20 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04912 for ; Tue, 5 Feb 2002 12:09:20 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Feb 2002 12:09:19 -0800 From: "Tony Hain" To: , "Tony Hain" Cc: "Vijay Devarapalli" , Subject: RE: Randomness and uniqueness Date: Tue, 5 Feb 2002 12:09:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk petrescu@crm.mot.com wrote: > Hi, the remark was born out mainly from my personal oppinions and > views on certain issues. I do not intend to boil any ocean. I'm > trying to find out some guidance on how one could put bits into > addresses. > > Alex Even though your purpose is different, a good place to start would be the discussion in RFC 3041 since the technical details will be similar. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 5 13:40:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Leu2Q011119 for ; Tue, 5 Feb 2002 13:40:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15Let9w011118 for ipng-dist; Tue, 5 Feb 2002 13:40:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Leq2Q011111 for ; Tue, 5 Feb 2002 13:40:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24589 for ; Tue, 5 Feb 2002 13:41:08 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA23611 for ; Tue, 5 Feb 2002 14:41:07 -0700 (MST) Received: (qmail 21725 invoked from network); 5 Feb 2002 21:40:55 -0000 Received: from pd9e4ef28.dip.t-dialin.net (HELO worker.muc.bieringer.de) (217.228.239.40) by mail.bieringer.de with SMTP; 5 Feb 2002 21:40:55 -0000 Date: Tue, 05 Feb 2002 22:40:55 +0100 From: Peter Bieringer To: ipng@sunroof.eng.sun.com Subject: RE: Randomness and uniqueness Message-ID: <76790000.1012945255@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b1 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Tuesday, February 05, 2002 10:01:06 AM -0800 Tony Hain wrote: > As you point out uniqueness is not guaranteed, even for > administrative assignments. That is why RFC 2462 specifically > states: > The Duplicate Address Detection algorithm is > performed on all addresses, independent of whether > they are obtained via stateless or stateful > autoconfiguration. > > In a quick scan of 3041 I didn't see a reference to that, but it > was a fundemental assumption. If 3041 is updated it would probably > help to have a clear pointer back to 2462. During developing my tool "ipv6calc" last summer and implementing a RFC 3041 simulation (for demonstrations) I already detect such problem , too. I've noticed both authors and got response from both that they will update the draft based on RFC 3041 http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-temp-addresses- v2-00.txt See 3.2.1 (4), they already add a note now. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 01:33:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169Xk2Q013887 for ; Wed, 6 Feb 2002 01:33:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g169Xk36013886 for ipng-dist; Wed, 6 Feb 2002 01:33:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169Xh2Q013879 for ; Wed, 6 Feb 2002 01:33:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14853 for ; Wed, 6 Feb 2002 01:33:57 -0800 (PST) Received: from mailweb19.rediffmail.com ([203.199.83.143]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA02377 for ; Wed, 6 Feb 2002 02:33:55 -0700 (MST) Received: (qmail 533 invoked by uid 510); 6 Feb 2002 09:33:50 -0000 Date: 6 Feb 2002 09:33:50 -0000 Message-ID: <20020206093350.531.qmail@mailweb19.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 06 Feb 2002 09:33:50 -0000 MIME-Version: 1.0 From: "IPSix Developer" Reply-To: "IPSix Developer" To: ipng@sunroof.eng.sun.com Cc: aconta@lucent.com, deering@cisco.com, 6bone@ISI.EDU Subject: generic v6 tunneling Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g169Xh2Q013880 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1)With ref to section 3.3 of RFC 2473 : "The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets can be the same node". Does it mean tunnel exit-point IPv6 address and original packets destination IPv6 address are same? If they are same, how do we configure the route for the destination V6 address at the tunnel entry point? 2)With ref to section 7.1(a) of RFC 2473: When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . If the furthur received packets' size is larger than IPv6 min link MTU, again TOO BIG message will be sent and a looping will occur? how to avoid this? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 02:25:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16APE2Q014028 for ; Wed, 6 Feb 2002 02:25:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16APEed014027 for ipng-dist; Wed, 6 Feb 2002 02:25:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16APA2Q014020 for ; Wed, 6 Feb 2002 02:25:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22158 for ; Wed, 6 Feb 2002 02:25:25 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23617 for ; Wed, 6 Feb 2002 03:25:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16APFa21304; Wed, 6 Feb 2002 11:25:15 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA00947; Wed, 6 Feb 2002 11:25:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16APEg73338; Wed, 6 Feb 2002 11:25:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "IPSix Developer" cc: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: Re: generic v6 tunneling In-reply-to: Your message of 06 Feb 2002 09:33:50 GMT. <20020206093350.531.qmail@mailweb19.rediffmail.com> Date: Wed, 06 Feb 2002 11:25:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1)With ref to section 3.3 of RFC 2473 : "The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets can be the same node". Does it mean tunnel exit-point IPv6 address and original packets destination IPv6 address are same? => "can be" but usually they are configured to be different because: - this can too easily mess the routing system - there is no reason to encapsulate such packets (they can be sent directly). If they are same, how do we configure the route for the destination V6 address at the tunnel entry point? => there is already a route to the exit-point, not using the tunnel. If you try to misconfigure a tunnel with a route to the exit-point through the tunnel, good systems will detect the error and won't crash trying infinite encapsulation. But this is harder if the loop is distributed between different nodes so section 4 describes this kind of problems and some solutions (note that 4.1.2 check detects your problem). 2)With ref to section 7.1(a) of RFC 2473: When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . If the furthur received packets' size is larger than IPv6 min link MTU, again TOO BIG message will be sent => yes, ICMPv6 are sent on errors but are rate limited. and a looping will occur? => I believe your loop is errors on errors. There are two counter-measures: (draft-ietf-ipngwg-icmp-v3-02.txt section 2.4) - (c) Every ICMPv6 error message (type < 128) includes as much of the IPv6 offending (invoking) packet (the packet that caused the error) as will fit without making the error message packet exceed the minimum IPv6 MTU. - (e.1) An ICMPv6 error message MUST NOT be sent as a result of receiving an ICMPv6 error message. (don't forget (f) aka rate limitation too). how to avoid this? => understand and implement carefully the specs (:-)! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 02:50:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Aoe2Q014099 for ; Wed, 6 Feb 2002 02:50:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Aod23014098 for ipng-dist; Wed, 6 Feb 2002 02:50:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Aoa2Q014091 for ; Wed, 6 Feb 2002 02:50:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22627 for ; Wed, 6 Feb 2002 02:50:51 -0800 (PST) Received: from mailFA10.rediffmail.com ([202.54.124.179]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA03377 for ; Wed, 6 Feb 2002 03:50:49 -0700 (MST) Received: (qmail 9663 invoked by uid 510); 6 Feb 2002 10:50:11 -0000 Date: 6 Feb 2002 10:50:11 -0000 Message-ID: <20020206105011.9662.qmail@mailFA10.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 06 Feb 2002 10:50:11 -0000 MIME-Version: 1.0 From: "IPSix Developer" Reply-To: "IPSix Developer" To: "Francis Dupont" Cc: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: Re: Re: generic v6 tunneling Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g16Aob2Q014092 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The looping i'm refering to section 7.1(a) of RFC 2473, occurs when the ipv6 packet size is checked against the min. link MTU always- which is always 1280 (or PathMTU ???) I'm not refering to errors on errors loop. On Wed, 06 Feb 2002 Francis Dupont wrote : > In your previous mail you wrote: > > 1)With ref to section 3.3 of RFC 2473 : > > "The tunnel exit-point node, which decapsulates the > tunnel packets, > and the destination node, which receives the > resulting original > packets can be the same node". > > Does it mean tunnel exit-point IPv6 address and > original packets > destination IPv6 address are same? > > => "can be" but usually they are configured to be > different because: > - this can too easily mess the routing system > - there is no reason to encapsulate such packets (they > can be sent > directly). > > If they are same, how do we configure the route for > the destination > V6 address at the tunnel entry point? > > => there is already a route to the exit-point, not > using the tunnel. > > If you try to misconfigure a tunnel with a route to the > exit-point > through the tunnel, good systems will detect the error > and won't crash > trying infinite encapsulation. But this is harder if > the loop is distributed > between different nodes so section 4 describes this > kind of problems > and some solutions (note that 4.1.2 check detects your > problem). > > 2)With ref to section 7.1(a) of RFC 2473: > > When the IPv6 packet size is larger than IPv6 min > link MTU, the > ICMPv6 pkt too big msg is sent with MTU as > max(tunnel MTU, IPv6 min > link MTU) . > > If the furthur received packets' size is larger than > IPv6 min link > MTU, again TOO BIG message will be sent > > => yes, ICMPv6 are sent on errors but are rate limited. > > and a looping will occur? > > => I believe your loop is errors on errors. There are > two counter-measures: > (draft-ietf-ipngwg-icmp-v3-02.txt section 2.4) > - (c) Every ICMPv6 er IPv6 offending (invoking) packet (the packet that > caused the > error) as will fit without making the error message > packet > exceed the minimum IPv6 MTU. > - (e.1) An ICMPv6 error message MUST NOT be sent as a > result of > receiving an ICMPv6 error message. > (don't forget (f) aka rate limitation too). > > how to avoid this? > > => understand and implement carefully the specs (:-)! > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 03:41:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Bfq2Q014361 for ; Wed, 6 Feb 2002 03:41:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Bfpau014360 for ipng-dist; Wed, 6 Feb 2002 03:41:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Bfi2Q014345; Wed, 6 Feb 2002 03:41:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21351; Wed, 6 Feb 2002 03:41:58 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20149; Wed, 6 Feb 2002 03:41:57 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA17562; Wed, 6 Feb 2002 04:41:56 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id EAA20181; Wed, 6 Feb 2002 04:41:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Wed, 6 Feb 2002 04:41:53 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B9A572EC83; Wed, 6 Feb 2002 12:37:11 +0100 (CET) To: monet@nal.motlabs.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, seamoby@ietf.org Subject: Announce: monet list moved, archives available over http From: Alexandru Petrescu Date: 06 Feb 2002 12:41:51 +0100 Message-Id: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Please excuse cross-posting and multiple copies] Hi, This is to announce that the monet list has been moved to monet@nal.motlabs.com. Archives of discussions starting now as well as archives of discussions Dec 2001-Jan 2002 are available at: http://www.nal.motlabs.com/mailman/listinfo/monet All subscribers to the old monet list have been de-subscribed from it and re-subscribed to the new location. The subject line changed from Monet to monet, so your local filters might need update. Thanks, Alex PS: the change in hosting name was needed in order to deliver archives directly over the web. PPS: I still have delivery problems to three addresses, I will try to contact them personally. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 05:43:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16DhH2Q014910 for ; Wed, 6 Feb 2002 05:43:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16DhHfc014909 for ipng-dist; Wed, 6 Feb 2002 05:43:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16DhD2Q014895 for ; Wed, 6 Feb 2002 05:43:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07449 for ; Wed, 6 Feb 2002 05:43:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25424 for ; Wed, 6 Feb 2002 05:43:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19708; Wed, 6 Feb 2002 08:43:24 -0500 (EST) Message-Id: <200202061343.IAA19708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-05.txt Date: Wed, 06 Feb 2002 08:43:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-05.txt Pages : 32 Date : 05-Feb-02 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020205155655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020205155655.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 08:41:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16GfU2Q016045 for ; Wed, 6 Feb 2002 08:41:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16GfUch016044 for ipng-dist; Wed, 6 Feb 2002 08:41:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16GfR2Q016037 for ; Wed, 6 Feb 2002 08:41:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00140 for ; Wed, 6 Feb 2002 08:41:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11200 for ; Wed, 6 Feb 2002 08:41:31 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 06 Feb 2002 08:41:26 -0800 From: "Tony Hain" To: "IPSix Developer" , "Francis Dupont" Cc: , <6bone@ISI.EDU> Subject: RE: Re: generic v6 tunneling Date: Wed, 6 Feb 2002 08:41:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020206105011.9662.qmail@mailFA10.rediffmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your question seems to imply the interface underlying the tunnel has an MTU smaller than 1280, but the context of the question is IPv6 over IPv6. If the context is correct, the physical interface MTU must be 1280 or larger. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of IPSix Developer > Sent: Wednesday, February 06, 2002 2:50 AM > To: Francis Dupont > Cc: ipng@sunroof.eng.sun.com; 6bone@ISI.EDU > Subject: Re: Re: generic v6 tunneling > > > > The looping i'm refering to section 7.1(a) of RFC 2473, > occurs when the ipv6 packet size is checked against the > min. link MTU always- which is always 1280 (or PathMTU ???) > > I'm not refering to errors on errors loop. > > > > On Wed, 06 Feb 2002 Francis Dupont wrote : > > In your previous mail you wrote: > > > > 1)With ref to section 3.3 of RFC 2473 : > > > > "The tunnel exit-point node, which decapsulates the > > tunnel packets, > > and the destination node, which receives the > > resulting original > > packets can be the same node". > > > > Does it mean tunnel exit-point IPv6 address and > > original packets > > destination IPv6 address are same? > > > > => "can be" but usually they are configured to be > > different because: > > - this can too easily mess the routing system > > - there is no reason to encapsulate such packets (they > > can be sent > > directly). > > > > If they are same, how do we configure the route for > > the destination > > V6 address at the tunnel entry point? > > > > => there is already a route to the exit-point, not > > using the tunnel. > > > > If you try to misconfigure a tunnel with a route to the > > exit-point > > through the tunnel, good systems will detect the error > > and won't crash > > trying infinite encapsulation. But this is harder if > > the loop is distributed > > between different nodes so section 4 describes this > > kind of problems > > and some solutions (note that 4.1.2 check detects your > > problem). > > > > 2)With ref to section 7.1(a) of RFC 2473: > > > > When the IPv6 packet size is larger than IPv6 min > > link MTU, the > > ICMPv6 pkt too big msg is sent with MTU as > > max(tunnel MTU, IPv6 min > > link MTU) . > > > > If the furthur received packets' size is larger than > > IPv6 min link > > MTU, again TOO BIG message will be sent > > > > => yes, ICMPv6 are sent on errors but are rate limited. > > > > and a looping will occur? > > > > => I believe your loop is errors on errors. There are > > two counter-measures: > > (draft-ietf-ipngwg-icmp-v3-02.txt section 2.4) > > - (c) Every ICMPv6 er > IPv6 offending (invoking) packet (the packet that > > caused the > > error) as will fit without making the error message > > packet > > exceed the minimum IPv6 MTU. > > - (e.1) An ICMPv6 error message MUST NOT be sent as a > > result of > > receiving an ICMPv6 error message. > > (don't forget (f) aka rate limitation too). > > > > how to avoid this? > > > > => understand and implement carefully the specs (:-)! > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 10:49:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Inp2Q016292 for ; Wed, 6 Feb 2002 10:49:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Ino9T016291 for ipng-dist; Wed, 6 Feb 2002 10:49:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Inl2Q016284 for ; Wed, 6 Feb 2002 10:49:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10672 for ; Wed, 6 Feb 2002 10:50:03 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22166 for ; Wed, 6 Feb 2002 11:50:02 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g16Inlv04087; Wed, 6 Feb 2002 10:49:47 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO13793; Wed, 6 Feb 2002 10:49:36 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20020206093350.531.qmail@mailweb19.rediffmail.com> References: <20020206093350.531.qmail@mailweb19.rediffmail.com> Date: Wed, 6 Feb 2002 10:49:45 -0800 To: "IPSix Developer" From: Steve Deering Subject: Re: generic v6 tunneling Cc: ipng@sunroof.eng.sun.com, aconta@lucent.com, 6bone@ISI.EDU Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:33 AM +0000 2/6/02, IPSix Developer wrote: >1)With ref to section 3.3 of RFC 2473 : > "The tunnel exit-point node, which decapsulates the tunnel packets, and >the destination node, which receives the resulting original packets can >be the same node". > >Does it mean tunnel exit-point IPv6 address and original packets >destination IPv6 address are same? Possibly, but not necessarily. If the tunnel is treated as a separate link, the exit endpoint of the tunnel will have its own IPv6 address(es), distinct from those of the physical interface at which the tunnel terminates. But is also perfectly "legal" to send an IPv6 packet encapsulated within another IPv6 packet, in which both the inner and outer destination addresses are the same. > > If they are same, how do we configure >the route for the destination V6 address at the tunnel entry point? That is just an example of a router with more than one path to the same destination. That is handled as normal, either using routing protocols to choose the "shortest" or "best" path, or by configuration (a "static route"). >2)With ref to section 7.1(a) of RFC 2473: > >When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 >pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . > >If the furthur received packets' size is larger than IPv6 min link MTU, >again TOO BIG message will be sent and a looping will occur? how to >avoid this? If the source node ignores the Packet Too Big message and continues to send packets that exceed max(tunnel MTU, IPv6 min link MTU), those packets will be dropped and will trigger additional Packet Too Big messages, subject to the general rate limiting requirement imposed on transmitting ICMP error messages. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 10:54:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Isa2Q016403 for ; Wed, 6 Feb 2002 10:54:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16IsaMa016402 for ipng-dist; Wed, 6 Feb 2002 10:54:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16IsX2Q016395 for ; Wed, 6 Feb 2002 10:54:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22837 for ; Wed, 6 Feb 2002 10:54:49 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09743 for ; Wed, 6 Feb 2002 11:54:48 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g16Isce01944; Wed, 6 Feb 2002 10:54:39 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO14005; Wed, 6 Feb 2002 10:54:28 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> References: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> Date: Wed, 6 Feb 2002 10:54:37 -0800 To: Francis Dupont From: Steve Deering Subject: Re: generic v6 tunneling Cc: "IPSix Developer" , ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:25 AM +0100 2/6/02, Francis Dupont wrote: >> Does it mean tunnel exit-point IPv6 address and original packets >> destination IPv6 address are same? > > - there is no reason to encapsulate such packets (they can be sent > directly). That's not the case if the tunnel entry point node is not the original source node. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 11:51:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16JpM2Q016632 for ; Wed, 6 Feb 2002 11:51:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16JpM3K016631 for ipng-dist; Wed, 6 Feb 2002 11:51:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16JpJ2Q016624 for ; Wed, 6 Feb 2002 11:51:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06339 for ; Wed, 6 Feb 2002 11:51:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03953 for ; Wed, 6 Feb 2002 12:51:32 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16Jp4a05272; Wed, 6 Feb 2002 20:51:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA15317; Wed, 6 Feb 2002 20:51:05 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16Jp5g75964; Wed, 6 Feb 2002 20:51:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: "IPSix Developer" , ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: Re: generic v6 tunneling In-reply-to: Your message of Wed, 06 Feb 2002 10:54:37 PST. Date: Wed, 06 Feb 2002 20:51:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >> Does it mean tunnel exit-point IPv6 address and original packets >> destination IPv6 address are same? > > - there is no reason to encapsulate such packets (they can be sent > directly). That's not the case if the tunnel entry point node is not the original source node. => this changes nothing: in both cases there is a route to the destination and packets will follow it. The difference is they can be encapsulated or not, the visible source address doesn't matter... Regards Francis.Dupont@enst-bretagne.fr PS: differences can only be in source address based policies (QoS, IPsec, policy routing, etc). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 6 12:36:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Kau2Q016829 for ; Wed, 6 Feb 2002 12:36:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16KauKe016828 for ipng-dist; Wed, 6 Feb 2002 12:36:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Kaq2Q016821 for ; Wed, 6 Feb 2002 12:36:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25703 for ; Wed, 6 Feb 2002 12:37:07 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18069 for ; Wed, 6 Feb 2002 12:37:07 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g16Kawv09124; Wed, 6 Feb 2002 12:36:58 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO17693; Wed, 6 Feb 2002 12:36:46 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> References: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> Date: Wed, 6 Feb 2002 12:36:55 -0800 To: Francis Dupont From: Steve Deering Subject: Re: generic v6 tunneling Cc: "IPSix Developer" , ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:51 PM +0100 2/6/02, Francis Dupont wrote: > > - there is no reason to encapsulate such packets (they can be sent > > directly). > > That's not the case if the tunnel entry point node is not the original > source node. > >=> this changes nothing: in both cases there is a route to the >destination and packets will follow it. The difference is they can be >encapsulated or not, the visible source address doesn't matter... > >PS: differences can only be in source address based policies (QoS, IPsec, >policy routing, etc). Francis, Perhaps we are saying the same thing. If the tunnel entry point is other than the source node, that intermediate node has some reason to perform the encapsulation (security, performance, policy, whatever). Simply omitting the encapsulation -- which is what I thought you were suggesting -- may fail to satisfy the reason for the tunnel. Or in other words, encapsulation adds information to the packet (additional address(es), possibly different traffic class or flow label values, possibly extension headers). Simply removing that information changes the semantics of the packets, in possibly harmful ways. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 00:55:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g178tQ2Q019090 for ; Thu, 7 Feb 2002 00:55:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g178tQ2l019089 for ipng-dist; Thu, 7 Feb 2002 00:55:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g178tN2Q019082 for ; Thu, 7 Feb 2002 00:55:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25306 for ; Thu, 7 Feb 2002 00:55:38 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13376 for ; Thu, 7 Feb 2002 01:55:35 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 07 Feb 2002 14:41:23 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g178svm14332; Thu, 7 Feb 2002 14:24:57 +0530 Reply-To: From: "Murugan KAT" To: "'Erik Nordmark'" Cc: Subject: RE: ND - Neighbor Adv - 'O' Flag - clarification Date: Thu, 7 Feb 2002 14:42:05 +0530 Message-Id: <004901c1afb7$837f0460$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your detailed answer. -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Tuesday, 5 February 2002 2:35 PM To: murugankat@future.futsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Re: ND - Neighbor Adv - 'O' Flag - clarification > As per ND specification the Neighbor Advertisement message contains "O" > Flag (OverRide flag). > What is the purpose of this flag. Or when the nodes is supposed set this > Flag. Or when the nodes are not supposed to set this flag. The mechanical aspects of when it is set are covered in RFC 2460. > I suppose whenever the receiver finds a difference between the sent link > address and the address what it has in its ND cache it can modify the value. Correct. That is what RFC 2460 says. In addition there is some effect on the reachability state as specified in the rfc. > Why is this extra bit...? That question I don't think is clearly answered in the RFC. The motivation is that there are two possible approaches for dealing with information such as the link-layer address received in a ND packet: 1. The last received information takes precedence 2. The first received information takes precedence Normally #1 makes sense - the link layer address might change e.g. due to a replacement of the network adaptor or some form of failover between multiple adapters. But in the case of a neighbor solicitation #2 makes more sense - it is desirable by default to pick the first entity to respond since there is some correlation between the speed to respond and the load and/or speed of the node. Also, in the case of proxy neighbor advertisements it might make sense to make the precedence be determined by the sender of the NA. In the case of Mobile IP there is a home agent that proxies for a mobile node that is away from home. But in the case when the mobile moves home and start sending NA messages you'd like those message to take precedence over any proxy advertisements sent by the HA. (Of course the HA will be notified by the MN to stop sending the proxy advertisement but before it does the above rule makes sense.) The single override bit provides the flexibility to do all of the above. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 13:41:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Lex2Q022025 for ; Thu, 7 Feb 2002 13:40:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17LexcH022024 for ipng-dist; Thu, 7 Feb 2002 13:40:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Let2Q022017 for ; Thu, 7 Feb 2002 13:40:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22624 for ; Thu, 7 Feb 2002 13:41:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06472 for ; Thu, 7 Feb 2002 14:41:05 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17Lf0a00557; Thu, 7 Feb 2002 22:41:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA10619; Thu, 7 Feb 2002 22:41:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17Lf0g82041; Thu, 7 Feb 2002 22:41:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202072141.g17Lf0g82041@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of 05 Feb 2002 14:14:09 +0100. Date: Thu, 07 Feb 2002 22:41:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Hi, there's currently a stream of proposals that put random bits on the Interface ID of an IPv6 address. A background assumption is that the length of the Interface ID is 64 bits. => this is a strong assumption and all past threads about it concluded this assumption should *not* be done. Another assumption is that since those ID's are generated from random sources, then their uniqueness is guaranteed for practical purposes. => if this argument is used in order to avoid (or to perform after) DAD we have to define "practical". I agree with the probability argument (i.e. modulo implementation errors, collisions should be almost impossible) but I'd not like to get this in a life support system. May I point out the following: -mathematical uniqueness is not guaranteed, there's already an acknowledged collision probability. => this is why DAD should be always performed. According to my "please don't play Russion roulette with my network" argument, the control over to perform or not DAD should be in the hands of the network manager (not in the hands of the node manager because an address collision usually does *two* victims). -to this probability one should add "administrative probability" where same prefixes are accidentally assigned to two entities. => this is like link-layer address collision (for instance two Ethernet boards with the same MAC address in ROMs), the damage is done independently/before DAD, i.e. or we consider it can't happen, or we consider it is the business of someone else... -add implementation error probabilities, where a widespread implementation uses a weak algorithm to generate that random numbers, for example use as input time of day or the birth date, or short passphrases, etc. => this is a real concern (even there is a RFC about randomness). -add the p in prf. => ??? The last three factors are very hard to quantify, and as such the overall probability of collision events also seems to me very hard to quantify. Just a thought, born out of contemplating randomness. What do you think? => if it is not too late (I'm afraid it is), replace DAD by Duplicate Interface ID Detection. And, of course, perform DAD each time DAD can be useful (I know only one good exception: PPP, because PPP manages itself IIDs and guarantees against collisions). Regards Francis.Dupont@enst-bretagne.fr PS: I don't believe in RFC 3041: it doesn't provide privacy when the first 64 bits can be used to trace you. But it does provide near 2^63 different IIDs to the bad guy for source address spoofing! If you don't want to be traced by your IID, use ::1, ::2, ... as your IID and, of course, perform DAD. RFC 3041 is at the same level as the associated privacy concern... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 13:43:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Lhc2Q022035 for ; Thu, 7 Feb 2002 13:43:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17LhcLa022034 for ipng-dist; Thu, 7 Feb 2002 13:43:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17LhV2Q022027 for ; Thu, 7 Feb 2002 13:43:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28914 for ; Thu, 7 Feb 2002 13:43:47 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21993 for ; Thu, 7 Feb 2002 14:43:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17LhZa00754; Thu, 7 Feb 2002 22:43:35 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA10661; Thu, 7 Feb 2002 22:43:36 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17LhZg82054; Thu, 7 Feb 2002 22:43:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202072143.g17LhZg82054@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: "Alexandru Petrescu" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of Tue, 05 Feb 2002 10:01:06 PST. Date: Thu, 07 Feb 2002 22:43:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As you point out uniqueness is not guaranteed, even for administrative assignments. That is why RFC 2462 specifically states: The Duplicate Address Detection algorithm is performed on all addresses, independent of whether they are obtained via stateless or stateful autoconfiguration. => I agree, the only valid exception is PPP. In a quick scan of 3041 I didn't see a reference to that, but it was a fundemental assumption. => agree! Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 13:48:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Lm22Q022045 for ; Thu, 7 Feb 2002 13:48:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Lm2R5022044 for ipng-dist; Thu, 7 Feb 2002 13:48:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Llm2Q022037 for ; Thu, 7 Feb 2002 13:47:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25650 for ; Thu, 7 Feb 2002 13:48:00 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09197 for ; Thu, 7 Feb 2002 14:47:58 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17Llqa01378; Thu, 7 Feb 2002 22:47:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA10740; Thu, 7 Feb 2002 22:47:52 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17Llqg82077; Thu, 7 Feb 2002 22:47:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202072147.g17Llqg82077@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of 05 Feb 2002 19:31:07 +0100. Date: Thu, 07 Feb 2002 22:47:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: PS: with respect to uniqueness there's a draft on random Interface ID's without DAD: draft-soto-mobileip-random-iids-00.txt => this draft is about the probability argument. PPS: with respect to security there's ongoing discussion on Mobile IP, around a novel method to generate addresses (Computationally Generated Addresses). => there is no reason to avoid DAD on CGAs: CGAs and RFC 3041 are not different. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 13:58:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Lw92Q022079 for ; Thu, 7 Feb 2002 13:58:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Lw8Uw022078 for ipng-dist; Thu, 7 Feb 2002 13:58:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Lw42Q022071 for ; Thu, 7 Feb 2002 13:58:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26970 for ; Thu, 7 Feb 2002 13:58:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28845 for ; Thu, 7 Feb 2002 14:58:17 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17Lw7a02993; Thu, 7 Feb 2002 22:58:07 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA10951; Thu, 7 Feb 2002 22:58:07 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17Lw7g82125; Thu, 7 Feb 2002 22:58:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202072158.g17Lw7g82125@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: petrescu@crm.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of Tue, 05 Feb 2002 11:19:31 PST. Date: Thu, 07 Feb 2002 22:58:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As for using an address without performing DAD, this is a *bad idea* in general => I agree, at least using an address without performing DAD before should be explicitely allowed by the network manager (this can be easily added in fast-handoff). and fast-handoff is no excuse => I am afraid that fast-handoff is an excuse for mainly tendentious things... (:-) to avoid verifying that someone else is not already using an address on the link (assigned or random). If mip is that far off in the weeds we may need an AD to ask them to revisit their charter. => hum, what about this (from MIPv6 I-D 15): After forming a new care-of address, a mobile node MAY perform Duplicate Address Detection [27] on that new address to confirm its uniqueness. However, doing so represents a tradeoff between safety (ensuring that the new address is not used if it is a duplicate address) and overhead (performing Duplicate Address Detection requires the sending of one or more additional packets over what may be, for example, a slow wireless link through which the mobile node is connected). Performing Duplicate Address Detection also in general would cause a delay before the mobile node could use the new care-of address, possibly causing the mobile node to be unable to continue communication with correspondent nodes for some period of time. For these reasons, a mobile node, after forming a new care-of address, MAY begin using the new care-of address without performing Duplicate Address Detection. Furthermore, the mobile node MAY continue using the address without performing Duplicate Address Detection, although it SHOULD in most cases (e.g., unless network bandwidth or battery consumption for communication is of primary concern) begin Duplicate Address Detection asynchronously when it begins use of the address, allowing the Duplicate Address Detection procedure to complete in parallel with normal communication using the address. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 15:17:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NHa2Q022726 for ; Thu, 7 Feb 2002 15:17:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17NHZAm022725 for ipng-dist; Thu, 7 Feb 2002 15:17:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NHQ2Q022718 for ; Thu, 7 Feb 2002 15:17:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20884 for ; Thu, 7 Feb 2002 15:17:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22655 for ; Thu, 7 Feb 2002 15:17:31 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Feb 2002 15:17:13 -0800 From: "Tony Hain" To: , Cc: Subject: draft-ietf-ipngwg-dns-discovery-03.txt Date: Thu, 7 Feb 2002 15:17:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave & itojun, One area that could be added to the ANYCAST discussion is the point that the router could be configured to listen for these addresses & tunnel to a specific server. This would have the advantage of predictablility for diagnostics as well as per-subnet load distribution, with the down side being lowered robustness to server outages. In effect using the DHCP-proxy model at the IP layer. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 7 15:28:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NSS2Q022795 for ; Thu, 7 Feb 2002 15:28:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17NSSwi022794 for ipng-dist; Thu, 7 Feb 2002 15:28:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NSN2Q022787 for ; Thu, 7 Feb 2002 15:28:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04357 for ; Thu, 7 Feb 2002 15:28:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22979 for ; Thu, 7 Feb 2002 16:28:36 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Feb 2002 15:28:30 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DEA3@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGrSEo483PoTIwVRLiXvHXruEKpGAE5mRZw From: "Michel Py" To: "Tony Hain" , "Robert Elz" Cc: "Brian E Carpenter" , "JJ Behrens" , "Keith Moore" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17NSO2Q022788 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk About subnetting below /64, here is a quote from "ARIN Guidelines for Requesting Initial IPv6 Address Space" http://www.arin.net/regserv/ipv6/ipv6guidelines.html "The host portion of an IPv6 address is represented by the rightmost 64 bits of the address. A /64 SLA ID is the shortest network prefix that can be assigned to a site. The boundary between the network and host portions is "hard" and cannot be further subdivided." Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:00:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G0ZBJ000347 for ; Fri, 8 Feb 2002 08:00:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18G0ZaS000346 for ipng-dist; Fri, 8 Feb 2002 08:00:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G0QBJ000337 for ; Fri, 8 Feb 2002 08:00:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20527 for ; Fri, 8 Feb 2002 01:09:17 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16643 for ; Fri, 8 Feb 2002 02:09:16 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA18596 for ; Fri, 8 Feb 2002 02:09:16 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA01980 for ; Fri, 8 Feb 2002 02:09:15 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Fri, 8 Feb 2002 03:09:05 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3D5452EC83; Fri, 8 Feb 2002 10:04:21 +0100 (CET) To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness References: <200202072141.g17Lf0g82041@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 08 Feb 2002 10:09:08 +0100 In-Reply-To: <200202072141.g17Lf0g82041@givry.rennes.enst-bretagne.fr> Message-Id: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, thanks for following up on this. Francis Dupont writes: > -to this probability one should add "administrative probability" where > same prefixes are accidentally assigned to two entities. > > => this is like link-layer address collision (for instance two Ethernet > boards with the same MAC address in ROMs), the damage is done > independently/before DAD, i.e. or we consider it can't happen, > or we consider it is the business of someone else... Exactly. What I was trying to stress is that we're already subject to "collisions" due to a human factor: administrative errors. I know this is known, just felt like I wanted to see it here. > -add the p in prf. > > => ??? Sorry, not trying to be mysterious. Prf is short for pseudo-random function generators. The "pseudo" is sometimes "apparent". For the fun, two lines of a famous quote by von Neumann: "Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin". Just for the fun of it :-) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:02:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G2BBJ000446 for ; Fri, 8 Feb 2002 08:02:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18G2BV9000445 for ipng-dist; Fri, 8 Feb 2002 08:02:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G23BJ000430 for ; Fri, 8 Feb 2002 08:02:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04037 for ; Fri, 8 Feb 2002 08:02:18 -0800 (PST) From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn (mail1-smtp.szptt.net.cn [202.96.136.221]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA22240 for ; Fri, 8 Feb 2002 09:02:17 -0700 (MST) Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jmd3c641717; Fri, 8 Feb 2002 16:01:52 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm83c61a6cf; Wed, 6 Feb 2002 16:00:14 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA04396 for ietf-123-outbound.01@ietf.org; Wed, 6 Feb 2002 10:25:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA03618 for ; Wed, 6 Feb 2002 08:43:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19708; Wed, 6 Feb 2002 08:43:24 -0500 (EST) Message-Id: <200202061343.IAA19708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-05.txt Date: Wed, 06 Feb 2002 08:43:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-05.txt Pages : 32 Date : 05-Feb-02 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020205155655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020205155655.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:12:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GCbBJ000711 for ; Fri, 8 Feb 2002 08:12:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GCaD5000707 for ipng-dist; Fri, 8 Feb 2002 08:12:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GBfBN000669 for ; Fri, 8 Feb 2002 08:12:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00103 for ; Fri, 8 Feb 2002 00:28:04 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28456 for ; Fri, 8 Feb 2002 01:28:03 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA05328; Fri, 8 Feb 2002 09:28:01 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62238 from ; Fri, 8 Feb 2002 09:27:59 +0100 Message-Id: <3C638C0D.868FF077@hursley.ibm.com> Date: Fri, 08 Feb 2002 09:27:57 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Steve Deering Cc: Michel Py , JJ Behrens , Tony Hain , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.c a.us> <3C500710.B2025CBF@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > > At 2:07 PM +0100 1/24/02, Brian E Carpenter wrote: > >Nevertheless, it is not architecturally forbidden to subnet at /124 > >if you really want to... > > Actually, it is, at least for unicast addresses that do not start with > binary 000; see earlier message from me. How would you know I was doing it, from outside a site? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:22:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GMUBJ000975 for ; Fri, 8 Feb 2002 08:22:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GMUaC000974 for ipng-dist; Fri, 8 Feb 2002 08:22:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GM8BJ000943 for ; Fri, 8 Feb 2002 08:22:08 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g182XBBT017561 for ; Thu, 7 Feb 2002 18:33:11 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g182XAB3017560 for ipng@sunroof.eng.sun.com; Thu, 7 Feb 2002 18:33:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Fne2Q002585 for ; Mon, 4 Feb 2002 07:49:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04043 for ; Mon, 4 Feb 2002 07:49:54 -0800 (PST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17464 for ; Mon, 4 Feb 2002 08:49:48 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g14FnqZ08659 for ; Mon, 4 Feb 2002 17:49:52 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Feb 2002 17:49:47 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Feb 2002 17:49:43 +0200 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA28455; Mon, 4 Feb 2002 17:49:43 +0200 (EET) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g14FrMR09954; Mon, 4 Feb 2002 17:53:22 +0200 To: Gonzalo Camarillo , mmusic@ietf.org Cc: Hesham Soliman (ERA) , Pekka Savola , ipng@sunroof.eng.sun.com, seancolson@yahoo.com Subject: Re: [MMUSIC] RE: Last Call: Support for IPv6 in SDP to Proposed Standard References: <4DA6EA82906FD511BE2F00508BCF053802D4D0DD@Esealnt861.al.sw.ericsson.se> <3C59AA98.AEA5FAE5@lmf.ericsson.se> <3C59AA98.AEA5FAE5@lmf.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3C59AA98.AEA5FAE5@lmf.ericsson.se> Date: 04 Feb 2002 17:53:22 +0200 Message-ID: Lines: 121 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 04 Feb 2002 15:49:43.0986 (UTC) FILETIME=[908A3920:01C1AD93] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Gonzales, In message <3C59AA98.AEA5FAE5@lmf.ericsson.se> Gonzalo Camarillo writes: >Therefore, comments about the actual format are very welcome. Other >comments are interesting for other documents, but I do not think the >IESG has to be involved in such a discussion until those documents are >done. Would it be impossible (or too late) to align your spec with the updated format in sdp-new-04? It fixes the errors in your ABNF and it is mostly consistent with the syntax in RFC 2327. I have cut and pasted relevant ABNF from sdp-new-04 and RFC 2327 (FQDN and TTL are from old SDP) below. It is not strictly compatible with RFC 2327 as it fixes a bug with multicast-address rule (which could have more than 4 octets in RFC 2327): --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- 3. Syntax RFC2373 [1] gives an ABNF for the text representation of IPv6 addresses in Appendix B. RFC2732 [3] covers the text representation of IPv6 addresses when used within a URL. Using the ABNF described in these documents, the following updated ABNF for SDP is proposed. connection-address = multicast-address | addr multicast-address = addr "/" ttl [ "/" integer ] ;IPv4 multicast addresses must be in the range ;224.0.0.0 to 239.255.255.255 ;IPv6 multicast addresses must begin with the byte FF ;or include an IPv4 multicast address ttl = decimal-uchar addr = FQDN | unicast-address unicast-address = IP4-address | IP6-address FQDN = 4*(alpha-numeric|"-"|".") ;fully qualified domain name as specified in RFC1035 ; IP4-address, IP6-address: From RFC 2373 IP6-address = hexpart [ ":" IP4-address ] IP4-address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG uri = URI-reference ; defined in RFC2396/2732 ; decimal-uchar, integer, and alpha-numeric are defined in RFC2327 -->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8-- You could also discuss how TTL should be used with IPv6 addresses. While TTL is nice thing and makes it easy to recognize multicast addresses, it is not compatible with RFC2327 syntax. So, I propose something like following: --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- 4.2 IPv6 and Multicast Addresses The IPv6 multicast addresses have the following format: | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ A 8-bit prefix of all ones at the start of the address identitifies a multicast address. The text representation of the IPv6 multicast addresses begins always with a four-digit hex segment starting with "FF". Following the prefix are three reserved bits, initialized to zero, and a flag indicating how the address has been assigned. In text representation, the third hex-digit indicates if the multicast address is well-known (even digit) or transient (odd digit). The following four bits, scop, indicates the scope of the multicast address. The scop is the fourth hex-digit in the text representation. There is no TTL in IPv6, but the scope and group ID together identifies the multicast group. For multicast addresses mapped uniquely to IEEE 802 MAC addresses, the next 80 bits or 20 hex digits are reserved and must be zero. The last 32 bits identitifies the group within given scope. | 8 | 4 | 4 | 80 bits | 32 bits | +------ -+----+----+---------------------------+-----------------+ |11111111|flgs|scop| reserved must be zero | group ID | +--------+----+----+---------------------------+-----------------+ 4.2.1 Using TTL with IPv6 Multicast Address Conferences using an IPv6 multicast connection address SHOULD also have a time to live (TTL) value present in addition to the multicast address. The TTL and the IPv4 address together define the scope with which multicast packets sent in this conference will be sent. When an IPv4-compatible-IPv6 or IPv4-mapped-IPv6 address is used, TTL value MUST be in the range 0-255. When an IPv6 multicast connection address is used, a TTL value of 0 SHOULD is included. The TTL for the session is appended to the address using a slash as a separator. Examples are: c=IN IP6 FF1E::172A:1E24/0 c=IN IP6 ::233.42.30.36/16 -->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8-- Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:22:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GMEBJ000963 for ; Fri, 8 Feb 2002 08:22:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GME6q000962 for ipng-dist; Fri, 8 Feb 2002 08:22:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GM8BN000943 for ; Fri, 8 Feb 2002 08:22:11 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g182WcBT017553 for ; Thu, 7 Feb 2002 18:32:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g182WcC9017552 for ipng@sunroof.eng.sun.com; Thu, 7 Feb 2002 18:32:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VK522Q020330 for ; Thu, 31 Jan 2002 12:05:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12620 for ; Thu, 31 Jan 2002 12:05:18 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14208 for ; Thu, 31 Jan 2002 13:05:17 -0700 (MST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0VK5Ch04108; Thu, 31 Jan 2002 14:05:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0VK5CX09785; Thu, 31 Jan 2002 14:05:12 -0600 (CST) Received: from lmf.ericsson.se (rmt160168.am.ericsson.se [138.85.160.168]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA21661; Thu, 31 Jan 2002 14:05:08 -0600 (CST) Message-ID: <3C59AA98.AEA5FAE5@lmf.ericsson.se> Date: Thu, 31 Jan 2002 22:35:36 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: Pekka Savola , iesg@ietf.org, mmusic@ietf.org, ipng@sunroof.eng.sun.com, seancolson@yahoo.com Subject: Re: [MMUSIC] RE: Last Call: Support for IPv6 in SDP to Proposed Standard References: <4DA6EA82906FD511BE2F00508BCF053802D4D0DD@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The draft defines how to express IPv6 addresses in SDP. How you use this format is up to the application (i.e., outside the scope of this draft). Remember that SDP is used by many protocols (SIP, SAP, MGCP, RTSP). A good example is SIP. An MMUSIC document defines how to use SDP in conjunction with SIP. 3G systems, for instance, will use SDP and IPv6 together. They will define how to use this format when establishing a session. They will explicitly say which address you have to put in the c line (IPv4, or IPv6 or maybe FQDN). Therefore, comments about the actual format are very welcome. Other comments are interesting for other documents, but I do not think the IESG has to be involved in such a discussion until those documents are done. Regards, Gonzalo "Hesham Soliman (ERA)" wrote: > > I think Gonzalo already answered this. > Further clarifications are below, but > we might be getting off-topic for this draft. > > > (this way the receiving IPv6 node can decide the mechanism > > > > to reach the > > > > IPv4-address; that is, if u= can contain either IPv4 or > > > > IPv6 address) > > > > I'll restate this: this depends on the definition of u=. > > > > If 'u' can have: > > 1) only IPv6 addresses, using mapped address is fine > > 2) either iPv6 or IPv4 address, IMO IPv4 should be used > > when _sending_ > > the packet > > => See below. > > > > > We're arguing about point 2). My point is that if address > > can be either, > > some nodes [a dual stack] can receive values with u=[ipv4] > > _anyway_, and > > must be able to cope with them. > > => I was not conerned about dual stacked nodes, > they'll obviously understand. Some systems > require IPv6 only though, Others might prefer > to run IPv6 only for simplicity, so you shouldn't > assume dual stacks all the time. > > Hesham > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:25:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GP1BJ001103 for ; Fri, 8 Feb 2002 08:25:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GP1tU001102 for ipng-dist; Fri, 8 Feb 2002 08:25:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GL5BN000899 for ; Fri, 8 Feb 2002 08:24:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00361 for ; Fri, 8 Feb 2002 02:40:03 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04771 for ; Fri, 8 Feb 2002 02:40:03 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA09534 for ; Fri, 8 Feb 2002 03:40:02 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA09442 for ; Fri, 8 Feb 2002 03:40:02 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Fri, 8 Feb 2002 03:40:01 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 391AE2EC83; Fri, 8 Feb 2002 11:35:12 +0100 (CET) To: Francis Dupont Cc: "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness References: <200202081021.g18ALvg84903@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 08 Feb 2002 11:39:59 +0100 In-Reply-To: <200202081021.g18ALvg84903@givry.rennes.enst-bretagne.fr> Message-Id: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > => I believe you've mixed in a confusing way the uniqueness of an > address/IID on a link (guaranteed by DAD) and the uniqueness of > a CGA from the security point of view. They are very different > questions. Ok, I didn't want to generate any confusion. If that was the case, I'm retiring my argumentation, sorry. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:33:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GWxBJ001323 for ; Fri, 8 Feb 2002 08:32:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GWxov001322 for ipng-dist; Fri, 8 Feb 2002 08:32:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GSKBP001185 for ; Fri, 8 Feb 2002 08:32:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01385 for ; Thu, 7 Feb 2002 17:04:18 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29559 for ; Thu, 7 Feb 2002 18:04:17 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1814GP14953; Thu, 7 Feb 2002 17:04:16 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO52695; Thu, 7 Feb 2002 17:04:06 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200201311627.g0VGRUp17875@astro.cs.utk.edu> References: <200201311627.g0VGRUp17875@astro.cs.utk.edu> Date: Thu, 7 Feb 2002 17:04:26 -0800 To: Keith Moore From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: "Michel Py" , "Robert Elz" , "Brian E Carpenter" , "JJ Behrens" , "Tony Hain" , "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:27 AM -0500 1/31/02, Keith Moore wrote: >e.g. If an ISP gives its customers /64s they should still be able to subnet. >subnetting a /64 is a lot beter than NAT. Doing the multi-link subnet thing is a whole lot better than NAT as well. I.e., even if you only get a /64, you don't HAVE to do NAT in order to use multiple links. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:47:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GlFBJ001607 for ; Fri, 8 Feb 2002 08:47:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GlEOO001606 for ipng-dist; Fri, 8 Feb 2002 08:47:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Gk0BL001567 for ; Fri, 8 Feb 2002 08:46:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18663 for ; Fri, 8 Feb 2002 02:22:06 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16925 for ; Fri, 8 Feb 2002 03:22:04 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g18ALwa27295; Fri, 8 Feb 2002 11:21:58 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA18285; Fri, 8 Feb 2002 11:21:58 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g18ALvg84903; Fri, 8 Feb 2002 11:21:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202081021.g18ALvg84903@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of 08 Feb 2002 11:01:48 +0100. Date: Fri, 08 Feb 2002 11:21:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PPS: with respect to security there's ongoing discussion on Mobile IP, > around a novel method to generate addresses (Computationally > Generated Addresses). > > => there is no reason to avoid DAD on CGAs: CGAs and RFC 3041 are > not different. First, I find CGA (Computationally Generated Addresses) mechanisms to have valuable IP security properties and are probably exploitable in some contexts. => I agree, CGA have only two drawbacks: IPR (grrr!) and they are not for free (i.e. they involve some crypto operations). Is it reasonable to ask two distanced MN's to verify they haven't generated same CGA Interface ID? => DAD is a link operation. For clarification, I was suggesting that since IPv6 as is doesn't rely on mathematical uniqueness of random bits in Interface ID's, but enforces it with DAD, then it would seem natural that CGA mechanisms don't rely on that uniqueness either and should test it somehow. If I understand CGA mechanisms correctly, there's a low probability (ok, extremely low) for CGA'ed Interface ID's to collide. Those Interface ID's are not on the same subnet, different prefixes, DAD won't find collisions. The security verification of those CGA'ed Interface ID's happens at the Correspondent Node, against attacker MN's. => I believe you've mixed in a confusing way the uniqueness of an address/IID on a link (guaranteed by DAD) and the uniqueness of a CGA from the security point of view. They are very different questions. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 08:59:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GxFBJ001934 for ; Fri, 8 Feb 2002 08:59:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GxFwD001933 for ipng-dist; Fri, 8 Feb 2002 08:59:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GvtBN001899 for ; Fri, 8 Feb 2002 08:58:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09395 for ; Fri, 8 Feb 2002 01:23:43 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21754 for ; Fri, 8 Feb 2002 02:23:37 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1895fJ01384; Fri, 8 Feb 2002 16:05:41 +0700 (ICT) From: Robert Elz To: Steve Deering cc: Tomas Lund , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Feb 2002 16:05:41 +0700 Message-ID: <1382.1013159141@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Feb 2002 17:14:50 -0800 From: Steve Deering Message-ID: | There is yet another factor that limits the interface ID field to be no | less than 8 bits wide (i.e., no longer than a /120): RFC 2526 specifies | that the highest 127 interface ID values on each subnet are reserved for | well-known anycast addresses (as is the interface ID value zero). You | need at least 8 bits to hold those 127+1 anycast addresses, in addition | to the minimum of 2 IDs needed for the two ends of a point-to-point link. Yes, but just as with the subnet router anycast address, all these well known anycast addresses are meaningless on a point to point link. If the node sending the packet would bind one of those anycast addresses to itself, then it doesn't need to use anycast to find the server, it is the server, and no well known address is required. Otherwise, the remote node must be the server if there is one, and the remote node's unicast address might just as well be used instead of an anycast address. Since we're postulating a link with a subnet mask of indeterminate size (perhaps no more than /120 - but certainly with the possibility of it being longer than /64) there's no way for a remote node - one not connected to the link - to calculate the anycast addresses, it would have to be configured with the subnet mask (prefix length) for that to be possible (since it isn't on the link, it cannot be seeing RAs to announce it). If it is going to be configured (or look up in any kind of directory, DNS included) with anything at all related to a specific link, must better to just configure it with the unicast address to use, rather than a prefix / prefix-length combination for it to use in building an anycast address. Point to point links are just different than shared links - much of what is required on a shared link for it to operate (especially without specific configuration) simply isn't meaningful for a point to point link. Defining in an RFC that this should not be so doesn't make all that much tangible difference... Having said all that, and while retaining the firm belief that nothing we do should prohibit anyone from using /127 on a p2p if that's their desire, I'd also point out that /112 is an entirely sensible prefix length to use for such purposes. The 48 bits of address space between /64 and /112 is plenty for any conceivable purpose I can imagine (it is as much as we are allocating for numbering, hierarchically, all the organisations that will ever be connected) - so there shouldn't really be much in the way of rational demand for using longer prefixes than /112. And /112 has the nice property that in the textual format, the node numbed is the value after the final ':', so we get to use nnnn:1 and nnnn:2 for the two ends (or even nnnn:1111 and nnnn:2222 or something). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:01:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GxsCF001966 for ; Fri, 8 Feb 2002 09:01:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GYagQ001365 for ipng-dist; Fri, 8 Feb 2002 08:34:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GQiBX001140 for ; Fri, 8 Feb 2002 08:34:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20946 for ; Fri, 8 Feb 2002 02:01:58 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16975 for ; Fri, 8 Feb 2002 02:01:57 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id CAA18598 for ; Fri, 8 Feb 2002 02:51:19 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA23569 for ; Fri, 8 Feb 2002 02:50:37 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Fri, 8 Feb 2002 04:01:42 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A91C32EC83; Fri, 8 Feb 2002 10:57:01 +0100 (CET) To: Francis Dupont Cc: "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness References: <200202072147.g17Llqg82077@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 08 Feb 2002 11:01:48 +0100 In-Reply-To: <200202072147.g17Llqg82077@givry.rennes.enst-bretagne.fr> Message-Id: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > PPS: with respect to security there's ongoing discussion on Mobile IP, > around a novel method to generate addresses (Computationally > Generated Addresses). > > => there is no reason to avoid DAD on CGAs: CGAs and RFC 3041 are > not different. First, I find CGA (Computationally Generated Addresses) mechanisms to have valuable IP security properties and are probably exploitable in some contexts. Is it reasonable to ask two distanced MN's to verify they haven't generated same CGA Interface ID? For clarification, I was suggesting that since IPv6 as is doesn't rely on mathematical uniqueness of random bits in Interface ID's, but enforces it with DAD, then it would seem natural that CGA mechanisms don't rely on that uniqueness either and should test it somehow. If I understand CGA mechanisms correctly, there's a low probability (ok, extremely low) for CGA'ed Interface ID's to collide. Those Interface ID's are not on the same subnet, different prefixes, DAD won't find collisions. The security verification of those CGA'ed Interface ID's happens at the Correspondent Node, against attacker MN's. Again, I'm no CGA expert and as Jari and Vijay said, nothing in CGA'ed addresses stops them from being DAD'ed on the subnet. Alex > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:01:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GxsC9001966 for ; Fri, 8 Feb 2002 09:01:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GuA8n001887 for ipng-dist; Fri, 8 Feb 2002 08:56:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GsrBJ001871 for ; Fri, 8 Feb 2002 08:54:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12256 for ; Thu, 7 Feb 2002 16:57:47 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25716 for ; Thu, 7 Feb 2002 17:57:47 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g180vkP10812; Thu, 7 Feb 2002 16:57:46 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO52483; Thu, 7 Feb 2002 16:57:34 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 7 Feb 2002 16:57:55 -0800 To: JJ Behrens From: Steve Deering Subject: RE: IPv6 Addr/Prefix clarification Cc: Tony Hain , Michel Py , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:18 AM -0800 1/23/02, JJ Behrens wrote: >Please forgive me for being a newbie, but it seems wise to allow >subnetting of the lower 64 bits. Afterall, it would be terrible if my >dialup ISP assigned a /64 to me, and I had to rely on some IPv6 mythical >NAT to do subnetting! The IAB/IESG recommendation to the registries, which has subsequently been adopted by all of them, is that the default/standard unit of allocation to all end subscribers is a /48, and when they judge an ISP's utilization rate of IPv6 space, it will be on the basis of /48s per subscriber. Of course, the registries have no enforcement power that can prevent an ISP from making smaller allocations (i.e., longer prefixes), so we hope that market forces will do the job. At least an ISP will not be able to justify a longer prefix by claiming shortage of address space or registry requirements. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:31:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HTrEh004646 for ; Fri, 8 Feb 2002 09:31:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GGTla000770 for ipng-dist; Fri, 8 Feb 2002 08:16:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GBfBR000669 for ; Fri, 8 Feb 2002 08:16:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29009 for ; Fri, 8 Feb 2002 00:22:54 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03467 for ; Fri, 8 Feb 2002 01:22:54 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA03876; Fri, 8 Feb 2002 08:22:52 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA29592; Fri, 8 Feb 2002 08:22:58 GMT Date: Fri, 8 Feb 2002 08:22:51 +0000 (GMT) From: Tim Chown To: Steve Deering cc: Tony Hain , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 7 Feb 2002, Steve Deering wrote: > >Would you apply the RFC3194 0.8 HD ratio to subnets within a single ISP? > > No, the plan as I understand it is to apply the HD ratio to the number > of /48s, when evaluating an ISP's application for more address space. So if an ISP came along and said "we have a million customers signed up, we want to give them static /48 prefixes to their current home xDSL lines, and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M) Of course, as Tony says, no such ISP exists yet, nor may it for some time. > If that's so, and taking high end of that prediction (12 billion), we > ought to be able to assign a half a dozen (70 billion / 12 billion) > static /48s to every living human (not just every "site" or household), > hierarchically structured for routing and allocation, at a manageable > HD ratio of 80%. And remember that's just with the 001 space. We can > use the rest of the space for the animals, aliens, robots and non-living > humans. The problem is, if our friend Mr Fleming is right, the aliens with be running IPv8 from some different galaxy/stargate prefix :-) Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:31:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HTrEj004646 for ; Fri, 8 Feb 2002 09:31:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GQrfH001164 for ipng-dist; Fri, 8 Feb 2002 08:26:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GQjBJ001141 for ; Fri, 8 Feb 2002 08:26:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19404 for ; Thu, 7 Feb 2002 17:44:56 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08801 for ; Thu, 7 Feb 2002 18:44:56 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g181ite19009; Thu, 7 Feb 2002 17:44:55 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO53823; Thu, 7 Feb 2002 17:44:44 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 7 Feb 2002 17:45:04 -0800 To: Tim Chown From: Steve Deering Subject: RE: IPv6 Addr/Prefix clarification Cc: Tony Hain , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:03 PM +0000 2/1/02, Tim Chown wrote: >If that's static /48's, the /29 boundary will need revision...(and >certainly a /35 would be useless to any medium ISP). Yes, those boundaries are currently under discussion in the registry community, and I certainly expect them to change. (Though as pointed out by Tony, those were intended just as *initial* allocations to ISPs before they have many IPv6 customers; ISPs with lots of customers will get bigger blocks, and if it works out as planned, in most cases those larger blocks will include the initial smaller blocks, so that assigning more space to an ISP won't increase the number of routes to that ISP (but rather just shrink the prefix of the existing route). >Would you apply the RFC3194 0.8 HD ratio to subnets within a single ISP? No, the plan as I understand it is to apply the HD ratio to the number of /48s, when evaluating an ISP's application for more address space. >I don't see that provider networks would be flat or near 100% utilisation >as you suggest in your previous email. No, and that's not what the policies under discussion in the RIRs assume. By the way, if I've operated my calculator correctly, there are approximately 35 trillion /48s in the 001-prefix part of the IPv6 address space. Applying the HD ratio calculation to that number yields: HD = .80 ("manageable") = 70 billion HD = .85 ("painful") = 330 billion HD = .87 ("practical limit") = 610 billion (using U.S. definition of "billion", i.e., 10^9) I read a reference to an article recently (in Science or some comparable journal; I really need to hunt it down) that stated that the current world population is about 6.1 billion and that population scientists are projecting that human population will hit its peak sometime around 2070, though the predicted peak number varies widely between 9 and 12 billion. If that's so, and taking high end of that prediction (12 billion), we ought to be able to assign a half a dozen (70 billion / 12 billion) static /48s to every living human (not just every "site" or household), hierarchically structured for routing and allocation, at a manageable HD ratio of 80%. And remember that's just with the 001 space. We can use the rest of the space for the animals, aliens, robots and non-living humans. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:31:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HTrEn004646 for ; Fri, 8 Feb 2002 09:31:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GP1NR001104 for ipng-dist; Fri, 8 Feb 2002 08:25:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GL5BP000899 for ; Fri, 8 Feb 2002 08:24:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19980 for ; Fri, 8 Feb 2002 02:11:07 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11853 for ; Fri, 8 Feb 2002 03:11:06 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g18AB1a25445; Fri, 8 Feb 2002 11:11:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA17997; Fri, 8 Feb 2002 11:11:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g18AB1g84782; Fri, 8 Feb 2002 11:11:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202081011.g18AB1g84782@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of 08 Feb 2002 10:09:08 +0100. Date: Fri, 08 Feb 2002 11:11:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => this is like link-layer address collision (for instance two Ethernet > boards with the same MAC address in ROMs), the damage is done > independently/before DAD, i.e. or we consider it can't happen, > or we consider it is the business of someone else... Exactly. What I was trying to stress is that we're already subject to "collisions" due to a human factor: administrative errors. => administrators are *responsible* of administrative errors: this makes the difference. > -add the p in prf. > > => ??? Sorry, not trying to be mysterious. Prf is short for pseudo-random function generators. The "pseudo" is sometimes "apparent". For the fun, two lines of a famous quote by von Neumann: "Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin". Just for the fun of it :-) => I agree that an algorithm cannot give a random number by definition of what are an algorithme and a random number. But some hardware devices (available on i810 chipset serie for instance) give good quality random numbers... (obviously an overkilling in this case :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:32:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HWeBJ005053 for ; Fri, 8 Feb 2002 09:32:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18HWeoj005052 for ipng-dist; Fri, 8 Feb 2002 09:32:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HVXBJ005039 for ; Fri, 8 Feb 2002 09:31:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25132 for ; Fri, 8 Feb 2002 09:29:27 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21249 for ; Fri, 8 Feb 2002 09:29:25 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g18HTDa21024; Fri, 8 Feb 2002 18:29:13 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA27038; Fri, 8 Feb 2002 18:29:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g18HTCg86248; Fri, 8 Feb 2002 18:29:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202081729.g18HTCg86248@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "marcelo bagnulo" cc: "Alexandru Petrescu" , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness In-reply-to: Your message of Fri, 08 Feb 2002 12:24:17 +0100. Date: Fri, 08 Feb 2002 18:29:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: if you do agree with the probablity argument but you do not like to implement it, because you do not like it, what are the reasons for this dislike? => the probability argument gives no guarantee. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 09:46:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HisG3006339 for ; Fri, 8 Feb 2002 09:46:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18HhDxa006192 for ipng-dist; Fri, 8 Feb 2002 09:43:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HfMBL005711 for ; Fri, 8 Feb 2002 09:41:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02407 for ; Fri, 8 Feb 2002 03:18:54 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00244 for ; Fri, 8 Feb 2002 04:18:51 -0700 (MST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id D0FFD4333E; Fri, 8 Feb 2002 12:18:47 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp02.uc3m.es (Postfix) with ESMTP id C4B5299E6F; Fri, 8 Feb 2002 12:18:44 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id MAA13143; Fri, 8 Feb 2002 12:18:44 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id MAA21612; Fri, 8 Feb 2002 12:18:35 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: "Francis Dupont" , "Alexandru Petrescu" Cc: Subject: RE: Randomness and uniqueness Date: Fri, 8 Feb 2002 12:24:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200202072141.g17Lf0g82041@givry.rennes.enst-bretagne.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Mensaje original----- De: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]En nombre de Francis Dupont Enviado el: jueves, 07 de febrero de 2002 22:41 Para: Alexandru Petrescu CC: ipng@sunroof.eng.sun.com Asunto: Re: Randomness and uniqueness > => if this argument is used in order to avoid (or to perform after) DAD > we have to define "practical". I agree with the probability argument > (i.e. modulo implementation errors, collisions should be almost impossible) > but I'd not like to get this in a life support system. if you do agree with the probablity argument but you do not like to implement it, because you do not like it, what are the reasons for this dislike? regards, m -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 11:33:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvTP014541 for ; Fri, 8 Feb 2002 11:33:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18IpcsB012375 for ipng-dist; Fri, 8 Feb 2002 10:51:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IjRDL010581 for ; Fri, 8 Feb 2002 10:50:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08067 for ; Fri, 8 Feb 2002 10:24:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16441 for ; Fri, 8 Feb 2002 11:24:43 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g18IOda26842; Fri, 8 Feb 2002 19:24:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA27749; Fri, 8 Feb 2002 19:24:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g18IOdg86701; Fri, 8 Feb 2002 19:24:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202081824.g18IOdg86701@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "marcelo bagnulo" cc: "Alexandru Petrescu" , ipng@sunroof.eng.sun.com, isoto@it.uc3m.es Subject: Re: Randomness and uniqueness In-reply-to: Your message of Fri, 08 Feb 2002 19:04:50 +0100. Date: Fri, 08 Feb 2002 19:24:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => the probability argument gives no guarantee. Nothing can give you full guarantees => globally unique IIDs give a full guarantee as I explained in a previous mail (with what is this guarantee). There is no option that always work, all the options work fine with a certain probability, The real question is if the probability that it fails is low enough. => no, the real question is who has to cleanup the mess when it fails. I prefer this guy has the control over the acceptable options too. And what does low enough means basically depends on the probablility of failure of the others elements related. So the question to be answered is if the probability of colision with random generated address identiers is low enough compared with the probability of failure of the other devices and protocols in the net. This is what we are trying to quantify. => there always is a difference between zero and not zero. It is also important to consider the cost, i.e. most of the times you can improve a solution (meaning that you can get a lower probability of failure) but this usually implies aditional costs, the question is if this is worthy. => worthy for who? If you takes the benefits and I have to take the problem in the case that should never happen but has just happened, my answer is a clear *no*. I mean whether you like it or not you are playing russian roulette :-), DAD can fail as well as all the other elements in your network => DAD is not perfect but my life is better with DAD than it would be without DAD. And I'd like to decide what is good for my network. This is the point I don't like at all in the MIPv6 I-D proposal, the MN user is not the person who may decide if he can avoid or defer DAD. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 11:33:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvTR014541 for ; Fri, 8 Feb 2002 11:33:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18IkZg1010968 for ipng-dist; Fri, 8 Feb 2002 10:46:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IiBDF010241 for ; Fri, 8 Feb 2002 10:45:42 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00838 for ; Fri, 8 Feb 2002 09:59:10 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06387 for ; Fri, 8 Feb 2002 09:59:08 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7335543279; Fri, 8 Feb 2002 18:59:06 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id 03CB799E6E; Fri, 8 Feb 2002 18:59:06 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id SAA31972; Fri, 8 Feb 2002 18:59:05 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA09673; Fri, 8 Feb 2002 18:59:05 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: Cc: "Alexandru Petrescu" , , Subject: RE: Randomness and uniqueness Date: Fri, 8 Feb 2002 19:04:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200202081729.g18HTCg86248@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Mensaje original----- > De: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Enviado el: viernes, 08 de febrero de 2002 18:29 > Para: marcelo bagnulo > CC: Alexandru Petrescu; ipng@sunroof.eng.sun.com > Asunto: Re: Randomness and uniqueness > > > In your previous mail you wrote: > > if you do agree with the probablity argument > but you do not like to implement it, because you do not like it, > what are the reasons for this dislike? > > => the probability argument gives no guarantee. Nothing can give you full guarantees There is no option that always work, all the options work fine with a certain probability, The real question is if the probability that it fails is low enough. And what does low enough means basically depends on the probablility of failure of the others elements related. So the question to be answered is if the probability of colision with random generated address identiers is low enough compared with the probability of failure of the other devices and protocols in the net. This is what we are trying to quantify. It is also important to consider the cost, i.e. most of the times you can improve a solution (meaning that you can get a lower probability of failure) but this usually implies aditional costs, the question is if this is worthy. I mean whether you like it or not you are playing russian roulette :-), DAD can fail as well as all the other elements in your network regards, m -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 11:45:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JjpBJ016188 for ; Fri, 8 Feb 2002 11:45:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18JjpAl016187 for ipng-dist; Fri, 8 Feb 2002 11:45:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JjSBJ016172 for ; Fri, 8 Feb 2002 11:45:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17368 for ; Fri, 8 Feb 2002 11:01:16 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12456 for ; Fri, 8 Feb 2002 12:01:15 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g18J1Fh02925; Fri, 8 Feb 2002 11:01:15 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO68446; Fri, 8 Feb 2002 11:01:04 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Fri, 8 Feb 2002 11:01:13 -0800 To: Tim Chown From: Steve Deering Subject: RE: IPv6 Addr/Prefix clarification Cc: Tony Hain , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:22 AM +0000 2/8/02, Tim Chown wrote: >So if an ISP came along and said "we have a million customers signed up, >we want to give them static /48 prefixes to their current home xDSL lines, >and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M) Yes, absolutely, assuming they can present some evidence that they really do have that many customers. Also, if the ISP were growing quickly enough they might well be given a bigger block than a /23, so they wouldn't have to come back again for more too soon. I believe the registries are considering taking growth rate into account, as well as customer count, when deciding how much space to allocate to an ISP. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 12:03:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvWt014541 for ; Fri, 8 Feb 2002 12:03:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Hu9NH007375 for ipng-dist; Fri, 8 Feb 2002 09:56:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HrXBJ007123 for ; Fri, 8 Feb 2002 09:53:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00015 for ; Thu, 7 Feb 2002 16:59:11 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18138 for ; Thu, 7 Feb 2002 17:59:11 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g180xAv17292; Thu, 7 Feb 2002 16:59:10 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO52547; Thu, 7 Feb 2002 16:58:59 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <3C500710.B2025CBF@hursley.ibm.com> References: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.c a.us> <3C500710.B2025CBF@hursley.ibm.com> Date: Thu, 7 Feb 2002 16:59:19 -0800 To: Brian E Carpenter From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: Michel Py , JJ Behrens , Tony Hain , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:07 PM +0100 1/24/02, Brian E Carpenter wrote: >Nevertheless, it is not architecturally forbidden to subnet at /124 >if you really want to... Actually, it is, at least for unicast addresses that do not start with binary 000; see earlier message from me. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 12:03:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvWl014541 for ; Fri, 8 Feb 2002 12:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18IBr5L008100 for ipng-dist; Fri, 8 Feb 2002 10:11:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IBfBN008067 for ; Fri, 8 Feb 2002 10:11:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09098 for ; Thu, 7 Feb 2002 16:49:51 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14646 for ; Thu, 7 Feb 2002 17:49:50 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g180noe16140; Thu, 7 Feb 2002 16:49:50 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO52220; Thu, 7 Feb 2002 16:49:39 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200201231602.g0NG2er04675@astro.cs.utk.edu> References: <200201231602.g0NG2er04675@astro.cs.utk.edu> Date: Thu, 7 Feb 2002 16:49:59 -0800 To: Keith Moore From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: irinadayal@netscape.net (Irina Dayal), ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:02 AM -0500 1/23/02, Keith Moore wrote: > > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits > > long? > >no. because nothing requires a site to use the lower 64 bits as an >interface ID - a site is free to subnet that space if it wishes. Actually, there *is* something that requires a site to use the lower 64 bits as an interface ID: the IPv6 address architecture spec. RFC-2373 says on the top of page 7: (2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. That wording has been revised in the most recent version of that spec, draft-ietf-ipngwg-addr-arch-v3-07.txt, removing the reference to "format prefixes" and introducing the term "Modified EUI-64 format" to distinguish the format we use in which we invert the value of one of the bits from the real EUI-64 format, but still saying the same thing (on the bottom of page 8): For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Note that there is an exception for addresses beginning with binary 000, which is where we have put things like the embedded NSAP addresses and several of the many forms of IPv6 addresses with embedded IPv4 addresses, which obviously don't have 64-bit interface IDs. So, in answer to Irina's question "Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long?" the answer is no: prefixes starting with 000 may well be longer than 64 bits. (Prefixes may also be shorter than 16 bits, since we have also removed the TLA, NLA notions from the updated address architecture, those properly being in the realm of address assignment policy, not architecture.) If Keith and kre want to ignore the requirement for 64-bit interface IDs, and can find implementations that will satisfy that desire, fine. But if they choose to use prefixes longer than /70, they'll have the additional operational headache of ensuring that the "u" bit which indicates whether or not the interface ID is globally unique is correctly set to zero, even though that bit now falls within the subnet (or higher-level) field of the address. Doesn't seem worth the hassle, and the need for longer prefixes for address conservation is not persuasive, to me. When I get asked about what assumptions can be made about unicast prefix lengths (e.g., by people designing route look-up implementations), I tell them that they should be prepared to handle any prefix length, but that it will probably be OK if prefixes between 65 and 127, inclusive, are handled in a slower path (i.e., if you can't build the fully-general mechanism at an acceptable cost, you probably won't get burned if you optimize for prefixes between 0 and 64, plus 128 (for "host routes")). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 12:18:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KEuQx020922 for ; Fri, 8 Feb 2002 12:18:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jii2d016062 for ipng-dist; Fri, 8 Feb 2002 11:44:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JiCBN015896 for ; Fri, 8 Feb 2002 11:44:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21180 for ; Fri, 8 Feb 2002 10:57:41 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29411 for ; Fri, 8 Feb 2002 10:57:40 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 44DCA433E0; Fri, 8 Feb 2002 19:57:39 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp02.uc3m.es (Postfix) with ESMTP id E597699E6C; Fri, 8 Feb 2002 19:57:38 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id TAA21768; Fri, 8 Feb 2002 19:57:38 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA18465; Fri, 8 Feb 2002 19:57:37 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: Cc: "Alexandru Petrescu" , , , Subject: RE: Randomness and uniqueness Date: Fri, 8 Feb 2002 20:03:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200202081824.g18IOdg86701@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Mensaje original----- > De: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > > In your previous mail you wrote: > > > => the probability argument gives no guarantee. > > Nothing can give you full guarantees > > => globally unique IIDs give a full guarantee as I explained > in a previous mail (with what is this guarantee). globally unique IIDs can give you full guarantees, right, but the implementation of globally unique IIDs can not. In any case, I do agree with you that globally unique IIDs is a good solution but today it is not available and it don´t seems to be in a short time (i would like to see one) > > There is no option that always work, > all the options work fine with a certain probability, The real > question is > if the probability that it fails is low enough. > > => no, the real question is who has to cleanup the mess when it fails. > I prefer this guy has the control over the acceptable options too. This is also an important aspect but if the probability of that mess is very low and the "solution" to avoid the mess is expensive (for example for handovers), what is better? > > And what does low enough > means basically depends on the probablility of failure of the others > elements related. So the question to be answered is if the > probability of > colision with random generated address identiers is low enough > compared with > the probability of failure of the other devices and protocols > in the net. > This is what we are trying to quantify. > > => there always is a difference between zero and not zero. zero is not real > > It is also important to consider the cost, i.e. most of the > times you can > improve a solution (meaning that you can get a lower > probability of failure) > but this usually implies aditional costs, the question is if > this is worthy. > > => worthy for who? If you takes the benefits and I have to take > the problem > in the case that should never happen but has just happened, my answer is > a clear *no*. Every mobile user gets the benefits avoiding the time needed for DAD, and a very small percentage of all users pay the price. This is the tradoff that we would like to quantify > > I mean whether you like it or not you are playing russian roulette :-), > DAD can fail as well as all the other elements in your network > > => DAD is not perfect but my life is better with DAD than it would be > without DAD. And I'd like to decide what is good for my network. > This is the point I don't like at all in the MIPv6 I-D proposal, > the MN user is not the person who may decide if he can avoid or defer DAD. > Life is not better with DAD for mobile users Regards, m -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 12:54:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KsOBJ025292 for ; Fri, 8 Feb 2002 12:54:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18KsO7s025291 for ipng-dist; Fri, 8 Feb 2002 12:54:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KsJBJ025284 for ; Fri, 8 Feb 2002 12:54:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13326 for ; Fri, 8 Feb 2002 12:54:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25463 for ; Fri, 8 Feb 2002 13:54:34 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g18KsN909977; Fri, 8 Feb 2002 15:54:23 -0500 (EST) Message-Id: <200202082054.g18KsN909977@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steve Deering cc: Tim Chown , Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: (Your message of "Fri, 08 Feb 2002 11:01:13 PST.") Date: Fri, 08 Feb 2002 15:54:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >So if an ISP came along and said "we have a million customers signed up, > >we want to give them static /48 prefixes to their current home xDSL lines, > >and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M) > > Yes, absolutely, assuming they can present some evidence that they > really do have that many customers. does the decision to use ASCII hex labels (rather than bitstrings) in ip6.arpa affect the allocation? would the RIRs be expected to dole out prefixes in 4-bit increments in order to make DNS delegation for PTR lookups easier? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 13:01:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KxuKV025424 for ; Fri, 8 Feb 2002 13:01:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Kr7Rw025283 for ipng-dist; Fri, 8 Feb 2002 12:53:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KiEOn022494 for ; Fri, 8 Feb 2002 12:52:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02286 for ; Thu, 7 Feb 2002 17:14:51 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23832 for ; Thu, 7 Feb 2002 18:14:50 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g181Eke01656; Thu, 7 Feb 2002 17:14:46 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO53016; Thu, 7 Feb 2002 17:14:31 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 7 Feb 2002 17:14:50 -0800 To: Tomas Lund From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: Robert Elz , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:02 PM +0100 2/1/02, Tomas Lund wrote: >On Fri, 1 Feb 2002, Robert Elz wrote: > > > | 3. Is it ok to use longer than a /64 for links ? > > > > That is, the suggestion isn't to pressure people to use /126 or something > > (as your #2 would do), nor to tell people that it isn't OK to use a /64 > >/127 seems alot better? Why waste 50%? There is yet another factor that limits the interface ID field to be no less than 8 bits wide (i.e., no longer than a /120): RFC 2526 specifies that the highest 127 interface ID values on each subnet are reserved for well-known anycast addresses (as is the interface ID value zero). You need at least 8 bits to hold those 127+1 anycast addresses, in addition to the minimum of 2 IDs needed for the two ends of a point-to-point link. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 13:01:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KxuKX025424 for ; Fri, 8 Feb 2002 13:01:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Kr6Wg025282 for ipng-dist; Fri, 8 Feb 2002 12:53:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KiEOh022494 for ; Fri, 8 Feb 2002 12:52:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12570 for ; Thu, 7 Feb 2002 17:51:06 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14050 for ; Thu, 7 Feb 2002 18:51:05 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g181p4e22577; Thu, 7 Feb 2002 17:51:04 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO53983; Thu, 7 Feb 2002 17:50:54 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200202011839.g11Idv918166@astro.cs.utk.edu> References: <200202011839.g11Idv918166@astro.cs.utk.edu> Date: Thu, 7 Feb 2002 17:51:13 -0800 To: Keith Moore From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: "Michel Py" , "Philip Homburg" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:39 PM -0500 2/1/02, Keith Moore wrote: >To me it seems entirely plausible that networks consisting of large >numbers of point-to-point links, assembled into trees, will be all the >rage in a few years. Even Ethernet is becoming more a point-to-point >technology rather than a bus technology. Like Ethernet bridges, we can do IP-layer "host routing" among an interconnected set of point-to-point links, treating the interconnected set as a single subnet (i.e., sharing a single /64). This is the multi- link subnet idea, and I think it would be a very nice way to handle residential and small office sites with multiple links, being just as "plug-and-play" as Ethernet bridges (no need to assign subnet numbers, etc.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 13:04:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18L49BJ026183 for ; Fri, 8 Feb 2002 13:04:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18L493k026182 for ipng-dist; Fri, 8 Feb 2002 13:04:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18L44BJ026175 for ; Fri, 8 Feb 2002 13:04:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12513 for ; Fri, 8 Feb 2002 12:50:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22576 for ; Fri, 8 Feb 2002 12:50:32 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18KoUS11030 for ; Fri, 8 Feb 2002 22:50:30 +0200 Date: Fri, 8 Feb 2002 22:50:30 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk These issues have also come up in the addr/prefix discussion; the issue was originally discussed in November. What do others think -- is this something worth noting? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ---------- Forwarded message ---------- Date: Tue, 05 Feb 2002 09:51:31 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Note about the Use of IPv6 /127 Prefix Length Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-00.txt Pages : 3 Date : 04-Feb-02 In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-ipv6-127-prefixlen-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-ipv6-127-prefixlen-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 13:28:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18LSgBJ027053 for ; Fri, 8 Feb 2002 13:28:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18LSgc8027052 for ipng-dist; Fri, 8 Feb 2002 13:28:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18LSdBJ027045 for ; Fri, 8 Feb 2002 13:28:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19761 for ; Fri, 8 Feb 2002 13:28:35 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25979 for ; Fri, 8 Feb 2002 13:28:35 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g18LSYE13047; Fri, 8 Feb 2002 13:28:34 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACO72846; Fri, 8 Feb 2002 13:28:19 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200202082054.g18KsN909977@astro.cs.utk.edu> References: <200202082054.g18KsN909977@astro.cs.utk.edu> Date: Fri, 8 Feb 2002 13:28:28 -0800 To: Keith Moore From: Steve Deering Subject: Re: IPv6 Addr/Prefix clarification Cc: Tim Chown , Tony Hain , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:54 PM -0500 2/8/02, Keith Moore wrote: > > >So if an ISP came along and said "we have a million customers signed up, > > >we want to give them static /48 prefixes to their current home xDSL lines, > > >and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M) > > > > Yes, absolutely, assuming they can present some evidence that they > > really do have that many customers. > >does the decision to use ASCII hex labels (rather than bitstrings) in ip6.arpa >affect the allocation? would the RIRs be expected to dole out prefixes in >4-bit increments in order to make DNS delegation for PTR lookups easier? I sure hope not. I have heard Randy and others claim that there is no reason to impose such a restriction, regardless of the dropping of the bitstring representation. Doesn't current IPv4 usage (which also doesn't use bitstrings, and which doesn't restrict CIDR prefixes to be only multiples of 4-bits long) provide a working example of how it can be done? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 15:11:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18NBOFh028155 for ; Fri, 8 Feb 2002 15:11:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18NBOq2028154 for ipng-dist; Fri, 8 Feb 2002 15:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18NBLFh028147 for ; Fri, 8 Feb 2002 15:11:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12822 for ; Fri, 8 Feb 2002 15:11:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27214 for ; Fri, 8 Feb 2002 16:11:35 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18NAfV12113; Sat, 9 Feb 2002 01:10:41 +0200 Date: Sat, 9 Feb 2002 01:10:40 +0200 (EET) From: Pekka Savola To: Steve Deering cc: Keith Moore , Tim Chown , Tony Hain , Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 8 Feb 2002, Steve Deering wrote: > At 3:54 PM -0500 2/8/02, Keith Moore wrote: > > > >So if an ISP came along and said "we have a million customers signed up, > > > >we want to give them static /48 prefixes to their current home xDSL lines, > > > >and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M) > > > > > > Yes, absolutely, assuming they can present some evidence that they > > > really do have that many customers. > > > >does the decision to use ASCII hex labels (rather than bitstrings) in ip6.arpa > >affect the allocation? would the RIRs be expected to dole out prefixes in > >4-bit increments in order to make DNS delegation for PTR lookups easier? > > I sure hope not. I have heard Randy and others claim that there is no > reason to impose such a restriction, regardless of the dropping of the > bitstring representation. Doesn't current IPv4 usage (which also doesn't > use bitstrings, and which doesn't restrict CIDR prefixes to be only > multiples of 4-bits long) provide a working example of how it can be done? Allocations on non-nibble boundaries are possible of course.. it could just mean about 8 different almost identical delegations in the worst case. Or are you referring to "Class-less reverse delegation" (RFC2317)? I'm not sure if that'd help all that much. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 23:23:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g197NwFh028792 for ; Fri, 8 Feb 2002 23:23:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g197NwBA028791 for ipng-dist; Fri, 8 Feb 2002 23:23:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g197NtFh028784 for ; Fri, 8 Feb 2002 23:23:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09070 for ; Fri, 8 Feb 2002 23:24:11 -0800 (PST) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04705 for ; Fri, 8 Feb 2002 23:23:57 -0800 (PST) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 5EC82362; Fri, 8 Feb 2002 23:23:52 -0800 (PST) Date: Fri, 8 Feb 2002 23:23:51 -0800 From: David Terrell To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-ID: <20020208232351.A4935@pianosa.catch22.org> Reply-To: David Terrell References: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.c <3C500710.B2025CBF@hursley.ibm.com> <3C638C0D.868FF077@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C638C0D.868FF077@hursley.ibm.com>; from brian@hursley.ibm.com on Fri, Feb 08, 2002 at 09:27:57AM +0100 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:19PM up 27 days, 19:57, 31 users, load averages: 1.23, 1.29, 1.27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Feb 08, 2002 at 09:27:57AM +0100, Brian E Carpenter wrote: > Steve Deering wrote: > > > > At 2:07 PM +0100 1/24/02, Brian E Carpenter wrote: > > >Nevertheless, it is not architecturally forbidden to subnet at /124 > > >if you really want to... > > > > Actually, it is, at least for unicast addresses that do not start with > > binary 000; see earlier message from me. > > How would you know I was doing it, from outside a site? You couldn't, of course. It's forbidden, but not enforced. -- David Terrell | "I am pleased that after years of this Administration's Nebcorp PM | strident opposition to the free and open use and dbt@meat.net | exportation of American encryption technology, the wwn.nebcorp.com | Administration finally has listened to those of us in **use OpenBSD** | Congress who long have urged | export decontrol to enable www.openbsd.org | American industry to compete in this important and dynamic EFNet #openbsd | worldwide market." - Sen. John Ashcroft, R-Mo., 9/17/1999 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 8 23:30:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g197UqFh028816 for ; Fri, 8 Feb 2002 23:30:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g197UqYA028815 for ipng-dist; Fri, 8 Feb 2002 23:30:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g197UmFh028808 for ; Fri, 8 Feb 2002 23:30:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24504 for ; Fri, 8 Feb 2002 23:30:49 -0800 (PST) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06904 for ; Sat, 9 Feb 2002 00:30:49 -0700 (MST) Received: by pianosa.catch22.org (Postfix, from userid 1000) id A201B362; Fri, 8 Feb 2002 23:30:46 -0800 (PST) Date: Fri, 8 Feb 2002 23:30:46 -0800 From: David Terrell To: Pekka Savola Cc: Steve Deering , Keith Moore , Tim Chown , Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-ID: <20020208233046.B4935@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Sat, Feb 09, 2002 at 01:10:40AM +0200 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:28PM up 27 days, 20:06, 30 users, load averages: 1.30, 1.29, 1.26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Feb 09, 2002 at 01:10:40AM +0200, Pekka Savola wrote: > Allocations on non-nibble boundaries are possible of course.. it could > just mean about 8 different almost identical delegations in the worst > case. > > Or are you referring to "Class-less reverse delegation" (RFC2317)? I'm > not sure if that'd help all that much. My understanding was that 2317 was only needed on sub /24 allocations, though of course it could be used to allocate a /17 "efficiently". I do not think 2317 should be propagated forward into ip6.arpa. The need is not present. -- David Terrell | "When we said that you needed to cut the dbt@meat.net | wires for ultimate security, we didn't Nebcorp Prime Minister | mean that you should go wireless instead." http://wwn.nebcorp.com/ | - Casper Dik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 9 06:27:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19ERcFh029099 for ; Sat, 9 Feb 2002 06:27:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g19ERcKa029098 for ipng-dist; Sat, 9 Feb 2002 06:27:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19ERYFh029091 for ; Sat, 9 Feb 2002 06:27:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15117 for ; Sat, 9 Feb 2002 06:27:37 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22293 for ; Sat, 9 Feb 2002 07:27:36 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g19ERUa10429; Sat, 9 Feb 2002 15:27:30 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA06588; Sat, 9 Feb 2002 15:27:30 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g19ERTg91579; Sat, 9 Feb 2002 15:27:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202091427.g19ERTg91579@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "marcelo bagnulo" cc: "Alexandru Petrescu" , ipng@sunroof.eng.sun.com, isoto@it.uc3m.es, alberto@it.uc3m.es Subject: Re: Randomness and uniqueness In-reply-to: Your message of Fri, 08 Feb 2002 20:03:23 +0100. Date: Sat, 09 Feb 2002 15:27:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => globally unique IIDs give a full guarantee as I explained > in a previous mail (with what is this guarantee). globally unique IIDs can give you full guarantees, right, but the implementation of globally unique IIDs can not. => if I understand your argument, your concern is for instance we can't guarantee uniqueness of MAC addresses. I agree but MAC address collisions make impressive damage independently (in fact before) of IID stuff so I consider uniqueness is guaranteed by my sledgehammer (to shutdown definitively the device) and my legal department (for the NIC seller). In any case, I do agree with you that globally unique IIDs is a good solution but today it is not available and it don´t seems to be in a short time => they are available... > => no, the real question is who has to cleanup the mess when it fails. > I prefer this guy has the control over the acceptable options too. This is also an important aspect but if the probability of that mess is very low => very low but not zero. and the "solution" to avoid the mess is expensive (for example for handovers), what is better? => if I am in the charge of the network and the price of the solution is not for me I may answer I'd like to get the solution. I believe we have exchanged enough messages to see our opinions are not different about the probability argument validity but are different about who should decide to apply it of not. For me the network manager should get the control of this choice, not the mobile user. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 10 16:13:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B0D7Fh001501 for ; Sun, 10 Feb 2002 16:13:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B0D7Fr001500 for ipng-dist; Sun, 10 Feb 2002 16:13:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B0D4Fh001493 for ; Sun, 10 Feb 2002 16:13:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14799 for ; Sun, 10 Feb 2002 16:13:06 -0800 (PST) Received: from max5.rrze.uni-erlangen.de (max5.rrze.uni-erlangen.de [131.188.3.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11139 for ; Sun, 10 Feb 2002 17:13:04 -0700 (MST) Received: from devil.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP; Mon, 11 Feb 2002 01:12:59 +0100 Received: (from unrz111@localhost) by devil.rrze.uni-erlangen.de (8.11.6/8.11.6) id g1B0DEU15849; Mon, 11 Feb 2002 01:13:14 +0100 (CET) (envelope-from unrz111) From: Jochen Kaiser Date: Mon, 11 Feb 2002 01:13:14 +0100 To: Peter Bieringer Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-Id: <20020211011314.B11683@devil.rrze.uni-erlangen.de> References: <2B81403386729140A3A899A8B39B046405DE8A@server2000.arneill- <3C5D1C84.FCAFDE0D@hursley.ibm.com> <47560000.1012765530@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <47560000.1012765530@localhost>; from pb@bieringer.de on Sun, Feb 03, 2002 at 08:45:30PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Feb 03, 2002 at 08:45:30PM +0100, Peter Bieringer wrote: > > > --On Sunday, February 03, 2002 12:18:28 PM +0100 Brian E Carpenter > wrote: > > > Count the light bulbs and electric motors in your house. I don't > > want to exclude *anything* for the future. Luxury cars already > > contain several CAN subnets. > > Bridging can solve the problem and it's cheaper than routing. > Perhaps a cost reduce factor. I doubt, that optmimizing a L2 structure is much cheaper then sophisticating a L3 structure. Look at the tuning, which cisco (or other major player) does with L2. You don't want this at the end-customers household since it needs monitoring and fine tuning and has many sources of errors. However, the end-customer side and the corresponding scenarios aren't examined enough for IPv6 so far. Is someone doing research in this field and has some papers to read? with kind regards, jochen kaiser university of erlangen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 10 16:27:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B0RGFh001520 for ; Sun, 10 Feb 2002 16:27:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B0RGF5001519 for ipng-dist; Sun, 10 Feb 2002 16:27:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B0RDFh001512 for ; Sun, 10 Feb 2002 16:27:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15813 for ; Sun, 10 Feb 2002 16:27:15 -0800 (PST) Received: from max5.rrze.uni-erlangen.de (max5.rrze.uni-erlangen.de [131.188.3.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21400 for ; Sun, 10 Feb 2002 16:27:10 -0800 (PST) Received: from devil.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP; Mon, 11 Feb 2002 01:27:08 +0100 Received: (from unrz111@localhost) by devil.rrze.uni-erlangen.de (8.11.6/8.11.6) id g1B0RKw16310; Mon, 11 Feb 2002 01:27:20 +0100 (CET) (envelope-from unrz111) From: Jochen Kaiser Date: Mon, 11 Feb 2002 01:27:20 +0100 To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification Message-Id: <20020211012720.C11683@devil.rrze.uni-erlangen.de> References: <2B81403386729140A3A899A8B39B046405DE8E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <2B81403386729140A3A899A8B39B046405DE8E@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Fri, Feb 01, 2002 at 10:18:09AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Feb 01, 2002 at 10:18:09AM -0800, Michel Py wrote: [...] > > One question: Who is going to configure the vlans and the > access-lists between them? Joe customer? > the vlan is not the problem since you can have a default vlan which is member on all switch ports. it's pre configured. but I see your point. ipv6 makes L3 easier for the end customer and in return he gets more fun with L2. strange world :-) jochen kaiser -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 10 20:12:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4CeFh001646 for ; Sun, 10 Feb 2002 20:12:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B4CeAY001645 for ipng-dist; Sun, 10 Feb 2002 20:12:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4CaFh001638 for ; Sun, 10 Feb 2002 20:12:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09528 for ; Sun, 10 Feb 2002 20:12:38 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA06671 for ; Sun, 10 Feb 2002 21:12:37 -0700 (MST) content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 10 Feb 2002 20:12:34 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C30D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification thread-index: AcGykwNlVkbDlxkNTeex4qQeJFcGQAAHzksg From: "Michel Py" To: "Jochen Kaiser" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1B4CbFh001639 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jochen Kaiser wrote: > the vlan is not the problem since you can have a default vlan > which is member on all switch ports. it's pre configured. Ah. Multiple subnets on a single VLAN. Maybe you can explain me the purpose of the multiple subnets, then. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 10 20:29:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4T7Fh001745 for ; Sun, 10 Feb 2002 20:29:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B4T7CW001744 for ipng-dist; Sun, 10 Feb 2002 20:29:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4T4Fh001737 for ; Sun, 10 Feb 2002 20:29:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15559 for ; Sun, 10 Feb 2002 20:29:06 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25333 for ; Sun, 10 Feb 2002 20:28:46 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1B4LsG04494; Mon, 11 Feb 2002 11:21:54 +0700 (ICT) From: Robert Elz To: Steve Deering cc: Keith Moore , irinadayal@netscape.net (Irina Dayal), ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: References: <200201231602.g0NG2er04675@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Feb 2002 11:21:54 +0700 Message-ID: <4492.1013401314@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Feb 2002 16:49:59 -0800 From: Steve Deering Message-ID: | Actually, there *is* something that requires a site to use the lower 64 | bits as an interface ID: the IPv6 address architecture spec. RFC-2373 | says on the top of page 7: That is a mistake. Requiring this for the addresses that we're currently allocating is a mistake of its own, pretending that we know how addresses are to be allocated forever into the future is just plain insane. Just look backwards a little - when IPv6 was first designed (even the first versions with 128 bit addresses - the SIPP stuff), the interface identifier was a 48 bit MAC address (or at least that's what we were assuming that would be enough for everything). Then we found out that the rest of the world had moved on, and this new thing called the EUI-64 was to be the new standard for future network technologies. So we changed. We have to retain the flexibility to change again, when the rest of the world invents some other new format of link level identification. It makes no sense to pretend that we own that specification, and that we are not going to allow anything other than an EUI-64 (or something that can be converted into one) to ever be used. What's more, there's nothing at all in IPv6 as we know it now that depends upon this - apart from auto-configuration of addresses, which is a very much link dependent activity (relies upon the link supporting multicast so addresses can be verified, lookups can be done, ...). Some potential new medium won't necessarily support this (and point to point links certainly don't need anything nearly so complex). Of course, it does no real harm to have statements like this in the spec (and having such things makes it easier to deal with organisations which would prefer to be more miserly than we would like in the allocation of numbers) - provided that no-one starts building code that actually depends upon this never being changed into the future. We can easily change the spec as soon as it becomes apparent that a change is needed - provided that no-one has relied upon it too heavily. That's what I am requesting - that implementors simply ignore all these pretend to be boundaries, except where they are actually important for something. | If Keith and kre want to ignore the requirement for 64-bit interface | IDs, and can find implementations that will satisfy that desire, fine. | But if they choose to use prefixes longer than /70, they'll have the | additional operational headache of ensuring that the "u" bit which Huh? Thanks all the same, but unless that 'u' bit ever actually gets a use that matters, I don't think I'll care too much. Nothing (certainly not anything outside my local network) has any business at all caring in the slightest what the internal format of my "interface identifiers" is. Sure - when I'm doing something like allocating some static addresses (or some randomly assigned ones) and mixing those with ones that are auto-configured that bit helps avoid unnecessary collisions, so it is useful to have. Beyond that it is a waste of space (that is, if it wasn't already in the EUI-64 format, we wouldn't be inventing it for IPv6). | indicates whether or not the interface ID is globally unique is correctly Since absolutely nothing cares if the interface ID is globally unique or not, this cannot really matter. What's more, since we allow addresses with 'u' == 0, nothing can really ever demand that we have globally unique addresses. That is, it simply isn't possible to retro-fit 8+8 onto IPv6 as we have it now, there are already too many non-unique "interface IDs" for there to be any chance of that at all. | When I get asked about what assumptions can be made about unicast prefix | lengths (e.g., by people designing route look-up implementations), I | tell them that they should be prepared to handle any prefix length, | but that it will probably be OK if prefixes between 65 and 127, inclusive, | are handled in a slower path (i.e., if you can't build the fully-general | mechanism at an acceptable cost, you probably won't get burned if you | optimize for prefixes between 0 and 64, plus 128 (for "host routes")). I have no particular problem with that - though I'd expect that where people will optimise will also be determined by their target market. For some, host routes (/128) won't be worth optimising either. For some, perhaps only prefixes up to /48 will need to be handled really quickly. For others, everything between 0 and /128 is likely to be equally important. All this just results in situating different implementations into different market niches. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 10 21:24:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B5OVFh001860 for ; Sun, 10 Feb 2002 21:24:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B5OVTw001859 for ipng-dist; Sun, 10 Feb 2002 21:24:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B5OSFh001852 for ; Sun, 10 Feb 2002 21:24:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15368 for ; Sun, 10 Feb 2002 21:24:31 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19048 for ; Sun, 10 Feb 2002 22:24:30 -0700 (MST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Feb 2002 21:24:22 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DEB1@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) thread-index: AcGw5Ntq/M1REPVfQPWLQ+gQpeR6pAB1PIwA From: "Michel Py" To: "Pekka Savola" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1B5OSFh001853 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > What do others think -- is this something worth noting? Overall, I find the text excellent. I oppose solutions 2,3 and 4 because they bring extra complexity to solve a problem that does not exist. The problem that does not exist is the need to subnet a /64. The reason /127 subnets have become popular is simply because of the old IPv4 habit of using a /30 for a point to point link. We collectively have to unlearn that. In other words, if operators are breaking RFC 2373 because of old working habits, the solution is to aquire new working habits, which is using a /64 for point-to-point links and stay in complicance with RFC2373, solution 1. It is clear that you were reading another thread on this same list, "IPv6 Addr/Prefix clarification". There are no reported RIR issues, and I still fail to see a valid reason to subnet a /64 when one should have used a /48 and subnet using the SLA bits. IPv6 is not widely deployed, why can't we just configure it right? I disagree with the phrasing that solution 1 is a workaround. Solution 1 is the way it is supposed to be. Solution 2 is a workaround, and not a very good one, IMHO. If an operator has to renumber point-to-point links configured with a /126, it makes a lot more sense to me to catch the opportunity to comply with RFC 2373 and give it a /64 instead. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 11 01:07:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B971Fh002011 for ; Mon, 11 Feb 2002 01:07:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B971Sl002010 for ipng-dist; Mon, 11 Feb 2002 01:07:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B96uFh002003 for ; Mon, 11 Feb 2002 01:06:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03782 for ; Mon, 11 Feb 2002 01:06:57 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06713 for ; Mon, 11 Feb 2002 01:06:56 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id BAA28429 for ; Mon, 11 Feb 2002 01:56:13 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA08444 for ; Mon, 11 Feb 2002 02:06:50 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Mon, 11 Feb 2002 02:06:49 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DA2F02EC83; Mon, 11 Feb 2002 10:01:46 +0100 (CET) To: "marcelo bagnulo" Cc: , , Subject: Re: Randomness and uniqueness References: From: Alexandru Petrescu Date: 11 Feb 2002 10:06:45 +0100 In-Reply-To: Message-Id: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "marcelo bagnulo" writes: > if the probability that it fails is low enough. And what does low > enough means basically depends on the probablility of failure of the > others elements related. Hi, just a quick note here: physicists build systems as probability products, but that only because laws are different in small worlds. :-) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 11 08:40:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BGefFh002980 for ; Mon, 11 Feb 2002 08:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BGeftf002979 for ipng-dist; Mon, 11 Feb 2002 08:40:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BGecFh002972 for ; Mon, 11 Feb 2002 08:40:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12148 for ; Mon, 11 Feb 2002 08:40:40 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20649 for ; Mon, 11 Feb 2002 08:40:35 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1BGeXa30811 for ; Mon, 11 Feb 2002 17:40:33 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA12126 for ; Mon, 11 Feb 2002 17:40:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1BGeXg98752 for ; Mon, 11 Feb 2002 17:40:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202111640.g1BGeXg98752@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: new draft Date: Mon, 11 Feb 2002 17:40:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've just sent a new I-D about IMEI-based universal interface IDs, I'd like to know when the addressing architecture version 3 document will be published (IESG status is AD revision) and if is there enough interest into IMEI IIDs to ask for a WG document... Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 11 22:53:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C6rAFh006606 for ; Mon, 11 Feb 2002 22:53:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C6r9KI006605 for ipng-dist; Mon, 11 Feb 2002 22:53:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C6r6Fh006598 for ; Mon, 11 Feb 2002 22:53:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA26005 for ; Mon, 11 Feb 2002 22:14:31 -0800 (PST) Received: from mailweb15.rediffmail.com ([203.199.83.27]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA02385 for ; Mon, 11 Feb 2002 23:14:30 -0700 (MST) Received: (qmail 27233 invoked by uid 510); 12 Feb 2002 06:12:55 -0000 Date: 12 Feb 2002 06:12:55 -0000 Message-ID: <20020212061255.27232.qmail@mailweb15.rediffmail.com> Received: from unknown (203.196.145.150) by rediffmail.com via HTTP; 12 Feb 2002 06:12:55 -0000 MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Query regarding loopback interface Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1C6r7Fh006599 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear sir/madam, Please answer the following question so that I can proceed further. Q) if we have any virtual link (ex. loopback) it will have a loopback address. Other than that, should we need to have any link local address for that interface. ? Anticipating your reply... regards, Ramakrishnan. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 11 23:08:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C78GFh006668 for ; Mon, 11 Feb 2002 23:08:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C78GmW006667 for ipng-dist; Mon, 11 Feb 2002 23:08:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C78AFh006660 for ; Mon, 11 Feb 2002 23:08:11 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1C784M12907; Tue, 12 Feb 2002 08:08:04 +0100 (MET) Date: Mon, 11 Feb 2002 23:37:31 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Randomness and uniqueness To: Alexandru Petrescu Cc: Francis Dupont , Tony Hain , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > First, I find CGA (Computationally Generated Addresses) mechanisms to > have valuable IP security properties and are probably exploitable in > some contexts. CGA = Cryptographically Generated Addresses Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 01:17:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C9HqFh007016 for ; Tue, 12 Feb 2002 01:17:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C9HqbI007015 for ipng-dist; Tue, 12 Feb 2002 01:17:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C9HlFh007008 for ; Tue, 12 Feb 2002 01:17:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21487 for ; Tue, 12 Feb 2002 01:17:49 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01294 for ; Tue, 12 Feb 2002 02:17:48 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA19913 for ; Tue, 12 Feb 2002 02:17:47 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA00382 for ; Tue, 12 Feb 2002 02:17:47 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 12 Feb 2002 03:17:35 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CF15B2EC83; Tue, 12 Feb 2002 10:12:37 +0100 (CET) To: Erik Nordmark Cc: Francis Dupont , Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: Randomness and uniqueness References: From: Alexandru Petrescu Date: 12 Feb 2002 10:17:40 +0100 In-Reply-To: Message-Id: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > > First, I find CGA (Computationally Generated Addresses) mechanisms to > > have valuable IP security properties and are probably exploitable in > > some contexts. > > CGA = Cryptographically Generated Addresses Right. EGA = Expensively Generated Addresses :-) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 05:15:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CDFXFh007959 for ; Tue, 12 Feb 2002 05:15:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CDFXgE007958 for ipng-dist; Tue, 12 Feb 2002 05:15:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CDFUFh007951 for ; Tue, 12 Feb 2002 05:15:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17884 for ; Tue, 12 Feb 2002 05:15:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01832 for ; Tue, 12 Feb 2002 06:15:31 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CDFEa01710; Tue, 12 Feb 2002 14:15:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA00970; Tue, 12 Feb 2002 14:15:14 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CDFEg02983; Tue, 12 Feb 2002 14:15:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121315.g1CDFEg02983@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Wed, 23 Jan 2002 10:40:49 PST. <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> Date: Tue, 12 Feb 2002 14:15:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt: - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name but not suitable for the basic API)? - 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-). - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing (note: only some Mobile IPv6 features are enough stable to be added today in the advanced API, another way is to mandate the definitions for the API in Mobile IPv6 (and other) documents) - 2.2.2: draft-ietf-ipngwg-icmp-name-lookups-08.txt ??? (same issue but the document should be published soon and it is too late to add definitions) - 2.4: IPComp again... - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined but there is nothing about sin6_scope_id (IMHO the behavior should be: raise an error if the interface is not in the zone, i.e. interface specification is a more accurate specification). 6.2 tries to explain but is not enough clear/formal about this point and misses the fact that the issue can be for both sin6_scope_id of the source (bind()) and destination (connect/send*()) socket addresses. - 6.2: why IPV6_PKTINFO is not simply forbidden for TCP (i.e. raise an error in place of ignore)? + 6.3: good explanation of IPV6_HOPLIMIT vs. basic API stuff! - 6.5: are some definitions of well known values useful? (IMHO this is the job of DiffServ WG to answer) - 9.2: this text should make clear the assumption of RFC 2460 recommended ordering is abusive. I propose to remove IPV6_RTHDRDSTOPTS which has no current use too, so we can get the same kind of text than for routing headers (known limitations, possibility for clever kernels (i.e. a kernel which knows that a tunnel encapsulation limit must be before the fragmentation header when a packet with a TEL is fragmented)). - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) - 11.4: there is a discussion about MTUs and extra headers added by the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should not take into account the headers. But this makes it less useful for the programmer... (note: this is just a philosophical question for the 2292ter) - 11.5: is IPV6_REACHCONF really useful (example)? - 12: see 9.2 Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 10:02:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI2qFh009872 for ; Tue, 12 Feb 2002 10:02:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CI2qMj009871 for ipng-dist; Tue, 12 Feb 2002 10:02:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI2mFh009864 for ; Tue, 12 Feb 2002 10:02:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07561 for ; Tue, 12 Feb 2002 10:02:52 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26736 for ; Tue, 12 Feb 2002 11:02:51 -0700 (MST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1CI2Xo11626; Wed, 13 Feb 2002 03:02:33 +0900 (JST) Date: Wed, 13 Feb 2002 03:02:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <200202121315.g1CDFEg02983@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200202121315.g1CDFEg02983@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 12 Feb 2002 14:15:14 +0100, >>>>> Francis Dupont said: > Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt: Thanks for the detailed comments. (But, yeah, this is a bit late. I just submitted the 05 version...) > - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name > but not suitable for the basic API)? I'm tempted to incorporate this into this API spec as a co-author of the scoping architecture draft, but I don't think the advanced API is the proper place to define the alias. sockaddr_in6 is definitely a product of the basic API, so if we decided to define the alias somewhere, the place should be "a kind of" basic API document. Just because the basic API spec is in the last stage of standardization cannot be the reason to define a new stuff in the advanced API. I hope you accept this position. > - 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-). Since this is not specific to IPv6, I don't think we'll have to incorporate this definition to this API spec (I admit IPPROTO_ESP and IPPROTO_AH are not specific to IPv6 either, but they are at least mandatory stuffs in IPv6 and are mentioned in RFC 2460). As I said the other day, we cannot just incorporate all the miscellaneous definitions to the advanced API spec... > - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing > (note: only some Mobile IPv6 features are enough stable to be added > today in the advanced API, another way is to mandate the definitions > for the API in Mobile IPv6 (and other) documents) > - 2.2.2: draft-ietf-ipngwg-icmp-name-lookups-08.txt ??? > (same issue but the document should be published soon and > it is too late to add definitions) One of the main decisions in recent revisions of this draft is that we should stick to already-standardized definitions, that is, definitions that are in an RFC status. We did not want to depend on moving targets. I tend to agree with the icmp-name-lookup stuff, but I believe we can live without the definitions, at least in this particular API document. > - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined but > there is nothing about sin6_scope_id (IMHO the behavior should be: > raise an error if the interface is not in the zone, i.e. interface > specification is a more accurate specification). > 6.2 tries to explain but is not enough clear/formal about this point > and misses the fact that the issue can be for both sin6_scope_id of > the source (bind()) and destination (connect/send*()) socket addresses. Section 6.7 describes how the outgoing interface is chosen. The items 1 to 5 in this section do not depend on the sin6_scope_id value of the source (specified by bind(2)) and destination (specified by connect(2) etc) addresses. And then the text says that the implementation should check the scope zone boundary wrt the outgoing interface and the scope zone of the source/destination addresses. Isn't this enough? If not, could you be a bit more specific on how the text should be? > - 6.2: why IPV6_PKTINFO is not simply forbidden for TCP (i.e. raise > an error in place of ignore)? Hmm, since there probably exists no TCP application that tries to set IPV6_PKTINFO for specifying the source address, it would be clearer to forbid this case. > - 6.5: are some definitions of well known values useful? > (IMHO this is the job of DiffServ WG to answer) I'm not sure about this comment. What exactly do you want in this section? Are you requiring some revise in this section? > - 9.2: this text should make clear the assumption of RFC 2460 recommended > ordering is abusive. I propose to remove IPV6_RTHDRDSTOPTS which > has no current use too, so we can get the same kind of text than > for routing headers (known limitations, possibility for clever kernels > (i.e. a kernel which knows that a tunnel encapsulation limit must be > before the fragmentation header when a packet with a TEL is fragmented)). Please let me make sure about this comment...are you proposing to remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper position of a destination options header (only with the IPV6_DSTOPTS option)? If so, how can a user specify a couple of destination options headers before and after a routing header? As for the recommended header ordering in RFC 2460, I don't mind to make more comments that we cannot always assume the recommended ordering (actually I tried to explain this fact throughout this document. the ordering is just a limitation in this particular API.). > - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) Do you mean the send() message should return an (immediate) error when the packet is not fit in the outgoing link MTU? But, as Erik explained in his reply to Vlad, we cannot always expect the immediate error. I admit the spec is a bit complex, but the spec should be generic enough (i.e. we cannot assume a particular type of OSes.) > - 11.4: there is a discussion about MTUs and extra headers added by > the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should > not take into account the headers. But this makes it less useful > for the programmer... (note: this is just a philosophical question > for the 2292ter) I understand your concern, but, anyway, the value returned by IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too big, the application can then adjust the packet size with succeeding MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). So, I'd propose to clarify that the MTU is an "IP MTU" (in your definition above) and can be larger than the actual current path MTU when the kernel inserts additional headers. Is it okay with you? > - 11.5: is IPV6_REACHCONF really useful (example)? Honestly, I personally do not see a practical usage of this option. At least I've never seen an application that uses it. I don't mind to remove this, but if any other person wants to keep it, I'll just leave the current text as is. The definition has been there since a quite old revision of the draft, and it can at least be implemented. > - 12: see 9.2 (again) I'm not 100% sure about the point. Do you propose to remove IPV6_RTHDRDSTOPTS from this section, too? (If we can reach consensus in 9.2, I'll of course revise this section accordingly.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 11:16:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJGJFh010283 for ; Tue, 12 Feb 2002 11:16:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJGJc8010282 for ipng-dist; Tue, 12 Feb 2002 11:16:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJGGFh010275 for ; Tue, 12 Feb 2002 11:16:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04480 for ; Tue, 12 Feb 2002 11:16:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22722 for ; Tue, 12 Feb 2002 12:16:16 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CJGAa12904; Tue, 12 Feb 2002 20:16:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA10964; Tue, 12 Feb 2002 20:16:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CJGAg05367; Tue, 12 Feb 2002 20:16:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Wed, 13 Feb 2002 03:02:30 +0900. Date: Tue, 12 Feb 2002 20:16:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt: Thanks for the detailed comments. (But, yeah, this is a bit late. I just submitted the 05 version...) => sorry... > - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name > but not suitable for the basic API)? Just because the basic API spec is in the last stage of standardization cannot be the reason to define a new stuff in the advanced API. => will be for the next version of the basic API... > - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing One of the main decisions in recent revisions of this draft is... => so we have to require the definitions somewhere (a rfc2292ter I-D?) > - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined... Section 6.7 describes how the outgoing interface is chosen. => I've missed this forward reference! > - 6.5: are some definitions of well known values useful? > (IMHO this is the job of DiffServ WG to answer) I'm not sure about this comment. What exactly do you want in this section? Are you requiring some revise in this section? => examples of a well known value are code points of class selectors (but they are not IPv6 specific). > - 9.2: this text should make clear the assumption of RFC 2460 recommended > ordering is abusive. I propose to remove IPV6_RTHDRDSTOPTS which > has no current use too, so we can get the same kind of text than > for routing headers (known limitations, possibility for clever kernels > (i.e. a kernel which knows that a tunnel encapsulation limit must be > before the fragmentation header when a packet with a TEL is fragmented)). Please let me make sure about this comment...are you proposing to remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper position of a destination options header (only with the IPV6_DSTOPTS option)? => yes If so, how can a user specify a couple of destination options headers before and after a routing header? => he cannot but he doesn't need it and he cannot specify a destination option header just before a fragmentation header. IPV6_RTHDRDSTOPTS is unnecessary and misleading. > - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) Do you mean the send() message should return an (immediate) error when the packet is not fit in the outgoing link MTU? But, as Erik explained in his reply to Vlad, we cannot always expect the immediate error. I admit the spec is a bit complex, but the spec should be generic enough (i.e. we cannot assume a particular type of OSes.) => I've read Erik's answer but just try to explain the MTU stuff to a common programmer... > - 11.4: there is a discussion about MTUs and extra headers added by > the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should > not take into account the headers. But this makes it less useful > for the programmer... (note: this is just a philosophical question > for the 2292ter) I understand your concern, but, anyway, the value returned by IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too big, the application can then adjust the packet size with succeeding MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). So, I'd propose to clarify that the MTU is an "IP MTU" (in your definition above) and can be larger than the actual current path MTU when the kernel inserts additional headers. Is it okay with you? => there is already a document about this so I don't believe you need to modify the 05 draft. This is more a remark for the other document (BTW I've found a candidate for the previous point :-). > - 11.5: is IPV6_REACHCONF really useful (example)? Honestly, I personally do not see a practical usage of this option. At least I've never seen an application that uses it. I don't mind to remove this, but if any other person wants to keep it, I'll just leave the current text as is. The definition has been there since a quite old revision of the draft, and it can at least be implemented. => I don't believe the "it can at least be implemented" argument is enough to keep something (the opposite is :-). > - 12: see 9.2 (again) I'm not 100% sure about the point. Do you propose to remove IPV6_RTHDRDSTOPTS from this section, too? (If we can reach consensus in 9.2, I'll of course revise this section accordingly.) => yes, please remove IPV6_RTHDRDSTOPTS from everywhere. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 11:51:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJp2Fh010762 for ; Tue, 12 Feb 2002 11:51:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJp2Qx010761 for ipng-dist; Tue, 12 Feb 2002 11:51:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJoxFh010754 for ; Tue, 12 Feb 2002 11:50:59 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12646 for ; Tue, 12 Feb 2002 11:51:01 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17262 for ; Tue, 12 Feb 2002 11:51:01 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6B2A42D05; Tue, 12 Feb 2002 14:51:00 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id D71361AEA; Tue, 12 Feb 2002 14:50:59 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1CJoxk28282; Tue, 12 Feb 2002 14:50:59 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id OAA0000059067; Tue, 12 Feb 2002 14:50:58 -0500 (EST) Message-ID: <3C697222.79485CB4@zk3.dec.com> Date: Tue, 12 Feb 2002 14:50:58 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont Cc: "jinmei@isl.rdc.toshiba.co.jp" , IPNG Working Group Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" References: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Francis Dupont wrote: > > If so, how can a user specify a couple of destination > options headers before and after a routing header? > > => he cannot but he doesn't need it and he cannot specify > a destination option header just before a fragmentation header. > IPV6_RTHDRDSTOPTS is unnecessary and misleading. > ... > > - 12: see 9.2 > > (again) I'm not 100% sure about the point. Do you propose to remove > IPV6_RTHDRDSTOPTS from this section, too? (If we can reach consensus > in 9.2, I'll of course revise this section accordingly.) > > => yes, please remove IPV6_RTHDRDSTOPTS from everywhere. Why do you belive the IPV6_RTHDRDSTOPTS is unnecessary? Is it because of the lack of options that would go into this header? Or is it because of the restrictive ordering (i.e 2460 recomended ordering)? -vlad P.S. >From what I remember of the discussion about header ordering constraints was to stabilize this API and then figure something out that would not be restrictive. ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 13:02:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CL25Fh011393 for ; Tue, 12 Feb 2002 13:02:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CL25SO011392 for ipng-dist; Tue, 12 Feb 2002 13:02:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CL1wFh011385 for ; Tue, 12 Feb 2002 13:01:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05052 for ; Tue, 12 Feb 2002 13:01:58 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22701 for ; Tue, 12 Feb 2002 14:01:57 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CL1oa20678; Tue, 12 Feb 2002 22:01:50 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA13091; Tue, 12 Feb 2002 22:01:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CL1og05994; Tue, 12 Feb 2002 22:01:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202122101.g1CL1og05994@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vladislav Yasevich cc: "jinmei@isl.rdc.toshiba.co.jp" , IPNG Working Group Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Tue, 12 Feb 2002 14:50:58 EST. <3C697222.79485CB4@zk3.dec.com> Date: Tue, 12 Feb 2002 22:01:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Why do you belive the IPV6_RTHDRDSTOPTS is unnecessary? Is it because of the lack of options that would go into this header? => this is the main reason. In fact the only destination option in the draft (or in a RFC), the tunnel encapsulation limit, needs to be in a place not in the recommended ordering. Or is it because of the restrictive ordering (i.e 2460 recomended ordering)? => we know this ordering is bad so there is no reason to insist to enforce it. IPV6_DSTOPTS is enough. P.S. From what I remember of the discussion about header ordering constraints was to stabilize this API and then figure something out that would not be restrictive. => we can't do all what we want so the minimum API is the best. One day we'll try to fix this with a more powerful API but KISS + clever kernel is the best for today. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 14:48:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMmrFh011750 for ; Tue, 12 Feb 2002 14:48:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CMmr84011749 for ipng-dist; Tue, 12 Feb 2002 14:48:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMmpFh011742 for ; Tue, 12 Feb 2002 14:48:51 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1CMmTbr007408 for ; Tue, 12 Feb 2002 14:48:29 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1CMmTuT007407 for ipng@sunroof.eng.sun.com; Tue, 12 Feb 2002 14:48:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1A5sHFh000084 for ; Sat, 9 Feb 2002 21:54:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06483 for ; Sat, 9 Feb 2002 21:54:19 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22690 for ; Sat, 9 Feb 2002 21:54:18 -0800 (PST) Received: from z.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id E16381B81 for ; Sun, 10 Feb 2002 00:54:13 -0500 (EST) Received: from z'ha'dum.hactrn.net (localhost [127.0.0.1]) by z.hactrn.net (Postfix) with ESMTP id 845B1254 for ; Sun, 10 Feb 2002 05:55:51 +0000 (GMT) Date: Fri, 08 Feb 2002 18:24:02 -0500 Message-ID: <86wuxn7e25.wl@z'ha'dum.hactrn.net> From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-Reply-To: References: User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Allocations on non-nibble boundaries are possible of course.. it could > just mean about 8 different almost identical delegations in the worst > case. Right. Which should trivially easy to automate for any organization big enough to need to worry about it. > Or are you referring to "Class-less reverse delegation" (RFC2317)? I'm > not sure if that'd help all that much. RFC 2317 describes a hack that's not particularly useful for IPv6. Even for IPv4 it's only useful in situations where there's an allocation boundary within the least significant label; the corresponding situation in the IPv6 case would imply an allocation boundary in the least significant nibble of the 128-bit IPv6 address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 14:49:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMnTFh011760 for ; Tue, 12 Feb 2002 14:49:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CMnTrK011759 for ipng-dist; Tue, 12 Feb 2002 14:49:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMnSFh011752 for ; Tue, 12 Feb 2002 14:49:28 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1CMn6br007416 for ; Tue, 12 Feb 2002 14:49:06 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1CMn6Rl007415 for ipng@sunroof.eng.sun.com; Tue, 12 Feb 2002 14:49:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C1bWFh006002 for ; Mon, 11 Feb 2002 17:37:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14304 for ; Mon, 11 Feb 2002 17:37:36 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26192 for ; Mon, 11 Feb 2002 17:37:35 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id UAA15439 for ipng@sunroof.eng.sun.com; Mon, 11 Feb 2002 20:37:33 -0500 (EST) Date: Mon, 11 Feb 2002 20:37:33 -0500 (EST) From: Dan Lanciani Message-Id: <200202120137.UAA15439@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: [much snipped] |and I still fail to see a valid reason to subnet |a /64 when one should have used a /48 and subnet using the SLA |bits. An obvious reason would be that the one who wishes to subnet the /64 is not the same one who should have used a /48, with the former one having little control over the latter one. Dan Lanciani ddl@danlan.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 16:15:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0FkFh012391 for ; Tue, 12 Feb 2002 16:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D0FklU012390 for ipng-dist; Tue, 12 Feb 2002 16:15:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0FhFh012383 for ; Tue, 12 Feb 2002 16:15:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13923 for ; Tue, 12 Feb 2002 16:15:46 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19773 for ; Tue, 12 Feb 2002 17:15:45 -0700 (MST) Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Date: Tue, 12 Feb 2002 16:15:40 -0800 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046406C318@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcG0F/TyP4tdy2ZOQa+zh5lD9B69UwAC2m4w From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1D0FhFh012384 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Dan Lanciani wrote: > An obvious reason would be that the one who wishes to subnet > the /64 is not the same one who should have used a /48, with > the former one having little control over the latter one. A dial-up connection gets a /48..... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 18:34:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D2YKFh012764 for ; Tue, 12 Feb 2002 18:34:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D2YK1G012763 for ipng-dist; Tue, 12 Feb 2002 18:34:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D2YHFh012756 for ; Tue, 12 Feb 2002 18:34:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05805 for ; Tue, 12 Feb 2002 18:34:19 -0800 (PST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00670 for ; Tue, 12 Feb 2002 19:34:18 -0700 (MST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g1D2X7g02612; Tue, 12 Feb 2002 21:33:07 -0500 Message-Id: <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-icmp-v3-02.txt Date: Tue, 12 Feb 2002 21:33:07 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In reviewing this ID prior to approving the IETF Last Call, I have the following questions/comments: > Rate limiting: > > The limit parameters (e.g., T or F in the above examples) MUST > be configurable for the node, with a conservative default value > (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 > percent). T= 0.5 seems fairly high. Why not .1 or .01 (on today's links). It might also be useful to point out that having too much rate limiting (in routers) causes problems for traceroute, since this has been experienced in practice. Indeed, if routers rate limit to one message every .5 seconds, today's traceroute would seem to become unusable in practice. Indeed, even at .1 seconds, traceroute won't hardly work anymore. I.e., the first probe will get trigger an ICMP error, the second one (some 20-30 ms later) will not, due to rate limiting, etc. Would it be better to move away completely from fixed time intervals and just say as a percentage of the link traffic? at least in the case of routers? So, question for the WG: Is the current text on this topic adequate, or should it be revised? security considerations could perhaps use some updating. It seems largely unchanged relative to RFC 2463. Has nothing really changed in our thinking here since 2463 came out? It doesn't seem to note that ESP can do authentication only now. Should ESP (w/o encryption) also be used if an SA exists? 1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message. add "in some cases"? There is an authorization questioned buried here. How does one know that a particular SA is authorized to speak on behalf of a particular IP address (or actually came from the message originator)? Note, this issue is one of the reasons why IPsec doesn't automatically solve the problem of authenticating MIPv6 BUs. 2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The ICMP checksum calculation provides a protection mechanism against changes by a malicious interceptor in the destination and source address of the IP packet carrying that message, provided the ICMP checksum field is protected against change by authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message. seems like if you have AH/ESP, that check alone provides you the additional protection. That it also covers the ICMP checksum is not really relevant... needs an IANA Considerations Section. Should probably say something like "IANA guidelines for the assignment of ICMP types and values are given in Section 7 of RFC 2780." This assumes that the IANA section there is appropriate and doesn't need updating. It would also be appropriate to indicate what the IANA guidelines should be for assigning new values for types defined in this document. (Some probably would just say that IANA won't need to define any, but some others probably need something more.) One sentence abstract. RFC editor will likely say you can do better. see http://www.rfc-editor.org/policy.html. In the introduction (not the abstract), please add a line saying that this document updates/replaces RFC 2463 (and add to references). The reference section should separate the normative references from those that are non-normative (see http://www.rfc-editor.org/policy.html). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 12 23:48:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D7mAFh013065 for ; Tue, 12 Feb 2002 23:48:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D7mAN2013064 for ipng-dist; Tue, 12 Feb 2002 23:48:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D7m6Fh013057 for ; Tue, 12 Feb 2002 23:48:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10171 for ; Tue, 12 Feb 2002 23:48:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11061 for ; Tue, 12 Feb 2002 23:48:06 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1D7lpT31199; Wed, 13 Feb 2002 09:47:51 +0200 Date: Wed, 13 Feb 2002 09:47:51 +0200 (EET) From: Pekka Savola To: Michel Py cc: Dan Lanciani , Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046406C318@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Feb 2002, Michel Py wrote: > > Dan Lanciani wrote: > > An obvious reason would be that the one who wishes to subnet > > the /64 is not the same one who should have used a /48, with > > the former one having little control over the latter one. > > A dial-up connection gets a /48..... No, dial-up connection _should_ get a /48.. I don't think this will happen too often in practise. And also consider e.g. dsl/dial-in internal to the company: they, for practical reasons, must get /64. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 00:24:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8OAFh013124 for ; Wed, 13 Feb 2002 00:24:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D8OA3V013123 for ipng-dist; Wed, 13 Feb 2002 00:24:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8O6Fh013116 for ; Wed, 13 Feb 2002 00:24:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13633 for ; Wed, 13 Feb 2002 00:24:08 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26541 for ; Wed, 13 Feb 2002 00:24:07 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1D8O3S31540; Wed, 13 Feb 2002 10:24:03 +0200 Date: Wed, 13 Feb 2002 10:24:02 +0200 (EET) From: Pekka Savola To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046405DEB1@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 10 Feb 2002, Michel Py wrote: > > What do others think -- is this something worth noting? > > Overall, I find the text excellent. > > I oppose solutions 2,3 and 4 because they bring extra > complexity to solve a problem that does not exist. The problem > that does not exist is the need to subnet a /64. IMO, 2) adds no complexity. 3 might be remotely sensible, but 3 and 4 both cannot be relied on.. so if you want to be sure, you always have to do either 1) or 2). I hope I made the problems with at least 4) sufficiently clear. > The reason /127 subnets have become popular is simply because > of the old IPv4 habit of using a /30 for a point to point > link. We collectively have to unlearn that. Well, and then there is also RFC3021, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links" which is more of the equivalent.. > It is clear that you were reading another thread on this same > list, "IPv6 Addr/Prefix clarification". There are no reported > RIR issues, and I still fail to see a valid reason to subnet > a /64 when one should have used a /48 and subnet using the SLA > bits. IPv6 is not widely deployed, why can't we just configure > it right? At least at one time, Randy Bush advocated /64's for IX's because they didn't need more.. If IX's get /48, this is no problem. Anyway, I see why people see /126 and such as lucrative: they need to assign only _one_ /64 for all point-to-point links. There might be e.g. a couple of hundred of them, and even though 200 of them could fit fine to 2^16 subnets, you'd still have to define the addressing a bit more carefully. > I disagree with the phrasing that solution 1 is a workaround. > Solution 1 is the way it is supposed to be. Solution 2 is a > workaround, and not a very good one, IMHO. If an operator has > to renumber point-to-point links configured with a /126, it > makes a lot more sense to me to catch the opportunity to > comply with RFC 2373 and give it a /64 instead. I didn't see the problem with the wording, but I'll change the text slighly to reflect to this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 00:41:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8fnFh013151 for ; Wed, 13 Feb 2002 00:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D8fnHe013150 for ipng-dist; Wed, 13 Feb 2002 00:41:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8fkFh013143 for ; Wed, 13 Feb 2002 00:41:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16963 for ; Wed, 13 Feb 2002 00:41:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01819 for ; Wed, 13 Feb 2002 00:41:36 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1D8fAu31686; Wed, 13 Feb 2002 10:41:10 +0200 Date: Wed, 13 Feb 2002 10:41:10 +0200 (EET) From: Pekka Savola To: Thomas Narten cc: Bob Hinden , Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Feb 2002, Thomas Narten wrote: > following questions/comments: > > > Rate limiting: > > > > The limit parameters (e.g., T or F in the above examples) MUST > > be configurable for the node, with a conservative default value > > (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 > > percent). > > T= 0.5 seems fairly high. Why not .1 or .01 (on today's links). > > It might also be useful to point out that having too much rate > limiting (in routers) causes problems for traceroute, since this has > been experienced in practice. Indeed, if routers rate limit to one > message every .5 seconds, today's traceroute would seem to become > unusable in practice. Indeed, even at .1 seconds, traceroute won't > hardly work anymore. I.e., the first probe will get trigger an ICMP > error, the second one (some 20-30 ms later) will not, due to rate > limiting, etc. > > Would it be better to move away completely from fixed time intervals > and just say as a percentage of the link traffic? at least in the case > of routers? > > So, question for the WG: Is the current text on this topic adequate, > or should it be revised? Well, I brought up the issue with traceroute when I noticed some major router vendors implemented timer-based mechanisms, and proposed the token-bucket mechanism (which is used quite often). Personally, I'm a bit unsatisfied how the examples are portrayed; IMO, timer-based should definitely go away, be put in last, huge disclaimers printed or whatever. Bandwidth-based does not really scale: same implementation could be used over 64kbit/s or 10Gbit/s links. What's the percentage there? Assuming sending ICMP errors require processor cycles, the latter might still use up too much CPU even with 0.01% ;-) Also personally, token bucket is IMO the only sensible way to handle this. > security considerations could perhaps use some updating. It seems largely > unchanged relative to RFC 2463. Has nothing really changed in our > thinking here since 2463 came out? ICMP, among others, can be used for many kinds of reflection attacks -- that is, like: src = dst = informational ICMP packet then router responds by sending (non-ratelimited) packets to , originated from . You kill two birds with one stone: flood the victim by using any node anywhere, and in the process, kill the CPU on the reflector node. :-) Mixing this with MIPv6 Home Address Option, the results would be even more disastrous. Not that there is all that much to be done about this.. :-( (this is partially discussed in draft-savola-ipv6-rh-ha-security-01.txt) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 01:23:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9NTFh013483 for ; Wed, 13 Feb 2002 01:23:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D9NTDG013482 for ipng-dist; Wed, 13 Feb 2002 01:23:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9NOFh013475 for ; Wed, 13 Feb 2002 01:23:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19428 for ; Wed, 13 Feb 2002 01:23:26 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18548 for ; Wed, 13 Feb 2002 02:21:16 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1D99b601857; Wed, 13 Feb 2002 16:10:17 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Dan Lanciani" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046406C318@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C318@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2002 16:09:36 +0700 Message-ID: <1855.1013591376@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 12 Feb 2002 16:15:40 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046406C318@server2000.arneill-py.sacramento.ca.us> | A dial-up connection gets a /48..... Always? Really? Sure, if you're dialing into an ISP, with a whole bunch of /48's to issue (as static assignments, or dynamically while a call is active) that works just fine. But I dial into my university (and I have a routed net in my house, as do many on this list I guess). The university is not an ISP, they're just an organisation. The university has a /48. From where does it get this extra /48 to issue to me when I dial in? The university has no interest in becoming an ISP, or getting a bigger block of numbers, one /48 is easily big enough for us (64K subnets is lots, we are managing quite well with a single /16 ("class B") that we've had since forever, with something like 1K subnets allocated (though very few current dial in users actually get more than /32 - just a few of us). That is, there's plenty of space in that /48 to allocate /64's to all of the dial in users that we have (even statically), as well as all the normal connectivity. But with a /64 allocated to me, and your theory of subnetting, how do I manage to number my house? And no, do not tell me to use a switch and a flat network, that isn't possible, and even if it were, I wouldn't do it. Things of course aren't even that simple .. my house is also a dial in provider, I can dial into it while I'm travelling, and then use its dial out link to the university for my connectivity. Even if you suggest that every university (and other company) should get a /40 (well, not big enough, 256 /48's is not nearly enough, say /36 or /37 might do) instead of the /48's we had planned for normal organisations (and now go recalculate whether the H ratio says we really have enough address bits) and is able to assign a /48 to my house, when it dials in, how does my house assign me the /48 you claim that all dialup users should get, when I dial it??? Of course, it doesn't matter what prefix you say that every dial in user must get, as soon as one dial in user dials into another dial in user, the prefix size is never enough - if we start demanding fixed allocation sizes. ("Dial in" here includes any kind of temporary connectivity, in fact, that it is dialed really makes no difference at all, my house could just as well have a fixed link to the university, when I lived close enough for it to be cheap enough, I did have). All we need here is flexibility - when I'm travelling (these days anyway) all I need is one /128 when I dial in - sometime in the future I might prefer to get something more than that (I can't see a /112 ever not being enough, there's just so much I can carry, no matter how small it gets, but this really doesn't matter). All of the fixed allocation designs assume some model of how connectivity must be achieved, that make no sense even now, and will make even less in the future. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 01:24:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9O0Fh013493 for ; Wed, 13 Feb 2002 01:24:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D9O0iK013492 for ipng-dist; Wed, 13 Feb 2002 01:24:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9NuFh013485 for ; Wed, 13 Feb 2002 01:23:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19504 for ; Wed, 13 Feb 2002 01:23:58 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26687 for ; Wed, 13 Feb 2002 02:23:29 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1D9GG601870; Wed, 13 Feb 2002 16:16:36 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> References: <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2002 16:16:16 +0700 Message-ID: <1868.1013591776@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 12 Feb 2002 21:33:07 -0500 From: Thomas Narten Message-ID: <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> | Would it be better to move away completely from fixed time intervals | and just say as a percentage of the link traffic? at least in the case | of routers? It should be revised, but should be specified as token bucket type specifications - that is, it should be possible to send a burst of ICMPs if they're needed, just as long as the long term rate doesn't get above N (N can be pkts/sec, or percentage of packets processed). The link traffic percentage model (alone) breaks down if there has been no traffic (N% of 0 is 0, no matter what N is). Make all rate limits be specified with a rate/second (and 2/sec, or T=0.5) as a nice conservative default (just default) I can handle, but with a burst count of about 20 (as dedfault) (10 seconds with none, and 20 can be sent very quickly again). | So, question for the WG: Is the current text on this topic adequate, | or should it be revised? Revise it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 01:41:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9fYFh013533 for ; Wed, 13 Feb 2002 01:41:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D9fXGm013532 for ipng-dist; Wed, 13 Feb 2002 01:41:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9fUFh013525 for ; Wed, 13 Feb 2002 01:41:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23666 for ; Wed, 13 Feb 2002 01:41:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02149 for ; Wed, 13 Feb 2002 02:41:31 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1D9fBa28725; Wed, 13 Feb 2002 10:41:11 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA21123; Wed, 13 Feb 2002 10:41:11 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1D9fAg08341; Wed, 13 Feb 2002 10:41:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202130941.g1D9fAg08341@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Thomas Narten cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt In-reply-to: Your message of Tue, 12 Feb 2002 21:33:07 EST. <200202130233.g1D2X7g02612@cichlid.adsl.duke.edu> Date: Wed, 13 Feb 2002 10:41:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: T= 0.5 seems fairly high. Why not .1 or .01 (on today's links). => I agree because T should be in milliseconds (f.1) and is against back-to-back erroneous packets. I propose 20ms (50Hz). So, question for the WG: Is the current text on this topic adequate, or should it be revised? => it should be improved! It doesn't seem to note that ESP can do authentication only now. Should ESP (w/o encryption) also be used if an SA exists? 1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message. => ESP cannot do authentication of the IPv6 header in transport mode, I vote to leave the text (with "can be achieved..." which is only an example). How does one know that a particular SA is authorized to speak on behalf of a particular IP address (or actually came from the message originator)? => because of the authentication part of any SA establishment protocol. Note, this issue is one of the reasons why IPsec doesn't automatically solve the problem of authenticating MIPv6 BUs. => no, the problem with MIPv6 is the authentication phase can (must in some cases) be done using a care-of address and the natural link between addresses and identies must be reported into the policy. There is no reason to do the same thing in the general case, i.e. default policies shall reject such strange things (there was some messages in the IPsec list about this). 2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The ICMP checksum calculation provides a protection mechanism against changes by a malicious interceptor in the destination and source address of the IP packet carrying that message, provided the ICMP checksum field is protected against change by authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message. seems like if you have AH/ESP, that check alone provides you the additional protection. That it also covers the ICMP checksum is not really relevant... => I agree the wording can be improved but where is the proposal for a new wording? needs an IANA Considerations Section. ... => agree (we have to get better habits :-) Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 04:09:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DC9BFh013749 for ; Wed, 13 Feb 2002 04:09:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DC9Bkh013748 for ipng-dist; Wed, 13 Feb 2002 04:09:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DC96Fh013741 for ; Wed, 13 Feb 2002 04:09:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04500 for ; Wed, 13 Feb 2002 04:09:08 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15541 for ; Wed, 13 Feb 2002 05:09:08 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28633; Wed, 13 Feb 2002 07:09:05 -0500 (EST) Message-Id: <200202131209.HAA28633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-05.txt Date: Wed, 13 Feb 2002 07:09:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-05.txt Pages : 80 Date : 12-Feb-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2292bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020212144032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020212144032.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 05:11:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DDBWFh013969 for ; Wed, 13 Feb 2002 05:11:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DDBVZG013968 for ipng-dist; Wed, 13 Feb 2002 05:11:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DDBSFh013961 for ; Wed, 13 Feb 2002 05:11:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05207 for ; Wed, 13 Feb 2002 05:11:31 -0800 (PST) Received: from fw1-a.osis.gov (fw1-a.osis.gov [204.178.104.233]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19304 for ; Wed, 13 Feb 2002 05:11:30 -0800 (PST) Received: from JMOLAFBEXCH1.jioc.osis.gov by fw1-a.osis.gov with ESMTP id IAA09139 (InterLock SMTP Gateway 4.2 for ); Wed, 13 Feb 2002 08:11:25 -0500 (EST) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) MIME-Version: 1.0 Date: Wed, 13 Feb 2002 07:11:24 -0600 Content-Type: text/plain; charset="US-ASCII" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Thread-Index: AcG0F+9rZnhj+UjyQ4e7CucKpiK1hQAd4WHg From: "SESVOLD, DALE" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1DDBTFh013962 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This has been going on for quite and while. And I keep asking myself -- Why not /60 for dialups? Its on a nice nibble and gives a good handfull of subnets for the SOHO. Dale Sesvold Senior Engineer MacAulay-Brown, Inc -----Original Message----- From: Dan Lanciani [mailto:ddl@ss10.danlan.com] Sent: Monday, February 11, 2002 7:38 PM To: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) "Michel Py" wrote: [much snipped] |and I still fail to see a valid reason to subnet |a /64 when one should have used a /48 and subnet using the SLA bits. An obvious reason would be that the one who wishes to subnet the /64 is not the same one who should have used a /48, with the former one having little control over the latter one. Dan Lanciani ddl@danlan.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 06:01:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DE19Fh014056 for ; Wed, 13 Feb 2002 06:01:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DE18Ma014055 for ipng-dist; Wed, 13 Feb 2002 06:01:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DE13Fh014048 for ; Wed, 13 Feb 2002 06:01:04 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1DE13M02422; Wed, 13 Feb 2002 15:01:03 +0100 (MET) Date: Wed, 13 Feb 2002 14:56:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - 11.4: there is a discussion about MTUs and extra headers added by > > the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should > > not take into account the headers. But this makes it less useful > > for the programmer... (note: this is just a philosophical question > > for the 2292ter) > > I understand your concern, but, anyway, the value returned by > IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too > big, the application can then adjust the packet size with succeeding > MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). > > So, I'd propose to clarify that the MTU is an "IP MTU" (in your > definition above) and can be larger than the actual current path MTU > when the kernel inserts additional headers. Is it okay with you? I think the philosophical question is deeper. Knowing the size of IP packets that can be sent without IP fragmentation (the path mtu) isn't that useful to an application when IP might add a variable amount of headers to the packet and the transport might in theory do the same. What would be useful to the application is something like "MAX_UNFRAGMENTED_SEND_SIZE" i.e. the largest amount of data that can be passed to send/sendto without causing IP fragmentation. Today with UDP over IPv6 the difference between this and path MTU is just a constant. But with mobile IP the sending IP stack some times inserts home address options and/or routing headers in which case the difference isn't constant. Of course, applications using sendmsg with ancillary data have more problems in this area since they need to know what size headers result from the ancillary data items they pass down e.g. that IPV6_HOPLIMIT doesn't add headers but IPV6_DSTOPTS does add. > > - 11.5: is IPV6_REACHCONF really useful (example)? > > Honestly, I personally do not see a practical usage of this option. > At least I've never seen an application that uses it. I don't mind to > remove this, but if any other person wants to keep it, I'll just leave > the current text as is. The definition has been there since a quite > old revision of the draft, and it can at least be implemented. An application like a DNS resolver library might pass this down on a sendmsg when it has recently gotten a reply from the same server. But the saving of the NUD probe in this case isn't yet a strong enough motivation to pass down IPV6_REACHCONF. It's hard to tell whether this motivation will be stronger in the future. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 08:52:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGq8Fh015194 for ; Wed, 13 Feb 2002 08:52:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGq7cD015193 for ipng-dist; Wed, 13 Feb 2002 08:52:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGq4Fh015186 for ; Wed, 13 Feb 2002 08:52:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17428 for ; Wed, 13 Feb 2002 08:52:07 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05406 for ; Wed, 13 Feb 2002 08:51:59 -0800 (PST) Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Date: Wed, 13 Feb 2002 08:51:23 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C322@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcG0Z+bi0l8T5CmySimDz6ZxBaIAkwARo2ww From: "Michel Py" To: "Pekka Savola" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1DGq4Fh015187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Dale, kre, others, I consolidated several postings into one.... >>> Dan Lanciani wrote: >>> An obvious reason would be that the one who wishes to subnet >>> the /64 is not the same one who should have used a /48, with >>> the former one having little control over the latter one. >> Michel Py wrote: >> A dial-up connection gets a /48..... > Pekka Savola wrote: > No, dial-up connection _should_ get a /48. Pekka, You are correct here. Since we are still in the early stages of deployment, it would be worth fixing it now. > And also consider e.g. dsl/dial-in internal to the > company: they, for practical reasons, must get /64. > Dale Sesvold wrote: > This has been going on for quite and while. And I keep asking > myself -- Why not /60 for dialups? Its on a nice nibble and gives > a good handfull of subnets for the SOHO. Absolutely. If you dial into your company, there is nothing that I know of that says you must get a /64. The allocation of the SLA bits is at the discretion of the company's network administrator, and allocating a /60 to the small number of sick individuals such as myself that insist on having subnets in their home is perfectly in line with RFC2373. > Pekka Savola wrote: > IMO, 2) adds no complexity. Poor choice of words. What is the word you would use to qualify violating RFC2373? > I hope I made the problems with at least 4) sufficiently clear. You have. As I said, I find your draft excellent, overall. Maybe a good canditate for a BCP. > kre wrote: > But I dial into my university (and I have a routed net in my house, > as do many on this list I guess). That would be interesting to know, actually. I think that most of us have an overkill setup at home, but I still have a single subnet. (I actually bridge things such as the ATM PVC to manage the DSL modem into the main subnet). However, I have an idle ethernet interface on my router that I will likely make a separate subnet. > (though very few current dial in users actually get more than /32 - > just a few of us). Same idea: These few of you can get a /60. A couple of beers with the network admin (when it's not you) typically can arrange that. I teach at University of California, I have my special drop behind the firewall. Two Fosters. You and I represent 1/1,000,000th of the population in terms of home setups. We should adapt to that fact, instead of trying to bend the standards to fit our needs. > But with a /64 allocated to me, and your theory of subnetting, how > do I manage to number my house? With a /64, you don't. And this is the point I am trying to make: you should get bigger. > And no, do not tell me to use a switch and a flat network, that > isn't possible, and even if it were, I wouldn't do it. Agree, I made that point myself a short while ago. > Pekka Savola wrote: > Anyway, I see why people see /126 and such as lucrative: they need > to assign only _one_ /64 for all point-to-point links. There might > be e.g. a couple of hundred of them, and even though 200 of them > could fit fine to 2^16 subnets, you'd still have to define the > addressing a bit more carefully. Actually, I don't see it that way. The /126 way: 3FFE:BEEF:CAFE:BABE::/64 is the block for p2p links 3FFE:BEEF:CAFE:BABE::/126 link 0 3FFE:BEEF:CAFE:BABE::4/126 link 1 3FFE:BEEF:CAFE:BABE::8/126 link 2 3FFE:BEEF:CAFE:BABE::C/126 link 3 The /64 way: 3FFE:BEEF:CAFE::/52 is the block for p2p links 3FFE:BEEF:CAFE::/64 link 0 3FFE:BEEF:CAFE:1::/64 link 1 3FFE:BEEF:CAFE:2::/64 link 2 3FFE:BEEF:CAFE:3::/64 link 3 Personally, I find the /64 way simpler. In the example above, it eats 1/16th of the /48 and allows for 4,096 links. Organisations with more than 4,096 links could use /51 or /50 and, if needed, request a /47 or a /46. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 10:08:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DI8iFh016124 for ; Wed, 13 Feb 2002 10:08:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DI8i1D016123 for ipng-dist; Wed, 13 Feb 2002 10:08:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DI8eFh016116 for ; Wed, 13 Feb 2002 10:08:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06844 for ; Wed, 13 Feb 2002 10:08:43 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28015 for ; Wed, 13 Feb 2002 11:08:42 -0700 (MST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1DI8Jo20293; Thu, 14 Feb 2002 03:08:19 +0900 (JST) Date: Thu, 14 Feb 2002 02:55:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 107 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 12 Feb 2002 20:16:10 +0100, >>>>> Francis Dupont said: >> - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing > One of the main decisions in recent revisions of this draft is... > => so we have to require the definitions somewhere (a rfc2292ter I-D?) Probably yes. (Particularly) as for mobile IPv6, it will need quite a lot of new API stuff and I think it is worth a separate draft. >> - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined... > Section 6.7 describes how the outgoing interface is chosen. > => I've missed this forward reference! Okay, then I'll just add a reference to Section 6.7 in 6.1. >> - 6.5: are some definitions of well known values useful? >> (IMHO this is the job of DiffServ WG to answer) > I'm not sure about this comment. What exactly do you want in this > section? Are you requiring some revise in this section? > => examples of a well known value are code points of class selectors > (but they are not IPv6 specific). Right, so I'll just keep the current text without mentioning particular traffic class values. (but I'll contact itojun, who is the author of the original draft of this Section, if I miss something here.) > Please let me make sure about this comment...are you proposing to > remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper > position of a destination options header (only with the IPV6_DSTOPTS > option)? > => yes > If so, how can a user specify a couple of destination > options headers before and after a routing header? > => he cannot but he doesn't need it and he cannot specify > a destination option header just before a fragmentation header. > IPV6_RTHDRDSTOPTS is unnecessary and misleading. Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's (even "advanced") applications. So I, for one, can live with the single option. However, I'm also quite sure this part is controversial. I'd like to know others opinions... >> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) > Do you mean the send() message should return an (immediate) error when > the packet is not fit in the outgoing link MTU? But, as Erik > explained in his reply to Vlad, we cannot always expect the immediate > error. I admit the spec is a bit complex, but the spec should be > generic enough (i.e. we cannot assume a particular type of OSes.) > => I've read Erik's answer but just try to explain the MTU stuff to > a common programmer... So, what do you want in this section? Are you requiring a change here? If so, please be more specific. >> - 11.4: there is a discussion about MTUs and extra headers added by >> the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should >> not take into account the headers. But this makes it less useful >> for the programmer... (note: this is just a philosophical question >> for the 2292ter) > I understand your concern, but, anyway, the value returned by > IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too > big, the application can then adjust the packet size with succeeding > MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). > So, I'd propose to clarify that the MTU is an "IP MTU" (in your > definition above) and can be larger than the actual current path MTU > when the kernel inserts additional headers. Is it okay with you? > => there is already a document about this so I don't believe you need > to modify the 05 draft. This is more a remark for the other document Okay, thanks. > (BTW I've found a candidate for the previous point :-). >> - 11.5: is IPV6_REACHCONF really useful (example)? > Honestly, I personally do not see a practical usage of this option. > At least I've never seen an application that uses it. I don't mind to > remove this, but if any other person wants to keep it, I'll just leave > the current text as is. The definition has been there since a quite > old revision of the draft, and it can at least be implemented. > => I don't believe the "it can at least be implemented" argument is > enough to keep something (the opposite is :-). Fair enough. Again, I don't mind to drop this section unless someone wants to keep it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 10:09:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DI9CFh016134 for ; Wed, 13 Feb 2002 10:09:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DI9CiW016133 for ipng-dist; Wed, 13 Feb 2002 10:09:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DI98Fh016126 for ; Wed, 13 Feb 2002 10:09:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24491; Wed, 13 Feb 2002 10:09:10 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27944; Wed, 13 Feb 2002 11:09:09 -0700 (MST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1DI94o20313; Thu, 14 Feb 2002 03:09:04 +0900 (JST) Date: Thu, 14 Feb 2002 03:09:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Feb 2002 14:56:52 +0100 (CET), >>>>> Erik Nordmark said: >> > - 11.4: there is a discussion about MTUs and extra headers added by (snip) >> So, I'd propose to clarify that the MTU is an "IP MTU" (in your >> definition above) and can be larger than the actual current path MTU >> when the kernel inserts additional headers. Is it okay with you? > I think the philosophical question is deeper. > Knowing the size of IP packets that can be sent without IP fragmentation > (the path mtu) isn't that useful to an application when IP might add a > variable amount of headers to the packet and the transport might in > theory do the same. > What would be useful to the application is something > like "MAX_UNFRAGMENTED_SEND_SIZE" > i.e. the largest amount of data that can be passed to send/sendto > without causing IP fragmentation. > Today with UDP over IPv6 the difference between this and path MTU is > just a constant. > But with mobile IP the sending IP stack some times inserts home address options > and/or routing headers in which case the difference isn't constant. > Of course, applications using sendmsg with ancillary data have more problems > in this area since they need to know what size headers result from > the ancillary data items they pass down e.g. that IPV6_HOPLIMIT > doesn't add headers but IPV6_DSTOPTS does add. (As a "philosophical" argument) I agree with all the points. But as for the API document, we should (or can) just keep the current text, as Francis agreed in his message. >> > - 11.5: is IPV6_REACHCONF really useful (example)? >> >> Honestly, I personally do not see a practical usage of this option. >> At least I've never seen an application that uses it. I don't mind to >> remove this, but if any other person wants to keep it, I'll just leave >> the current text as is. The definition has been there since a quite >> old revision of the draft, and it can at least be implemented. > An application like a DNS resolver library might pass this down > on a sendmsg when it has recently gotten a reply from the same server. > But the saving of the NUD probe in this case isn't yet a strong enough > motivation to pass down IPV6_REACHCONF. It's hard to tell whether this > motivation will be stronger in the future. Agreed, so, are you okay with removing this section? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 10:28:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DISeFh016400 for ; Wed, 13 Feb 2002 10:28:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DISe0A016398 for ipng-dist; Wed, 13 Feb 2002 10:28:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DISbFh016391 for ; Wed, 13 Feb 2002 10:28:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08433 for ; Wed, 13 Feb 2002 10:28:38 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01508 for ; Wed, 13 Feb 2002 10:28:37 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DISQk31991; Wed, 13 Feb 2002 19:28:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA03452; Wed, 13 Feb 2002 19:28:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DISRg10626; Wed, 13 Feb 2002 19:28:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131828.g1DISRg10626@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Wed, 13 Feb 2002 14:56:52 +0100. Date: Wed, 13 Feb 2002 19:28:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > > - 11.4: there is a discussion about MTUs and extra headers added by > > the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should > > not take into account the headers. But this makes it less useful > > for the programmer... (note: this is just a philosophical question > > for the 2292ter) > > I understand your concern, but, anyway, the value returned by > IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too > big, the application can then adjust the packet size with succeeding > MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). > > So, I'd propose to clarify that the MTU is an "IP MTU" (in your > definition above) and can be larger than the actual current path MTU > when the kernel inserts additional headers. Is it okay with you? I think the philosophical question is deeper. Knowing the size of IP packets that can be sent without IP fragmentation (the path mtu) isn't that useful to an application when IP might add a variable amount of headers to the packet and the transport might in theory do the same. => this was my motivation... An application can discover (with the DONTFLAG) the MTU is useless but this (DONTFRAG) doesn't provide an easy way to get the information. In fact only TCP has a TCP_MAXSEG which returns the MSS but TCP takes care of this too and headers can be different per protocol/port/etc. I believe to get the advanced API published is more important. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 11:15:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJFoFh017092 for ; Wed, 13 Feb 2002 11:15:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJFo3k017091 for ipng-dist; Wed, 13 Feb 2002 11:15:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJFkFh017084 for ; Wed, 13 Feb 2002 11:15:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29161 for ; Wed, 13 Feb 2002 11:15:47 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18220 for ; Wed, 13 Feb 2002 12:15:46 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id F128D3AEB; Wed, 13 Feb 2002 13:15:42 -0600 (CST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 8AD471BB6; Wed, 13 Feb 2002 14:15:40 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DJFc116309; Wed, 13 Feb 2002 14:15:38 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id OAA0000061498; Wed, 13 Feb 2002 14:15:42 -0500 (EST) Message-ID: <3C6ABB5D.20A2A1B4@zk3.dec.com> Date: Wed, 13 Feb 2002 14:15:41 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "jinmei@isl.rdc.toshiba.co.jp" Cc: Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" References: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya wrote: > > > Please let me make sure about this comment...are you proposing to > > remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper > > position of a destination options header (only with the IPV6_DSTOPTS > > option)? > > > => yes > > > If so, how can a user specify a couple of destination > > options headers before and after a routing header? > > > => he cannot but he doesn't need it and he cannot specify > > a destination option header just before a fragmentation header. > > IPV6_RTHDRDSTOPTS is unnecessary and misleading. > > Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's > (even "advanced") applications. So I, for one, can live with the > single option. However, I'm also quite sure this part is > controversial. I'd like to know others opinions... Well, for one, I don't see a good enough reason to remove this. This particular interface allows the user to specify the header that is discribed in 2460. Remembering how much discussion (trouble) we all had figuring out this DO Header stuff, I would leave this particular option there. This way, anyone trying to use 2460 header ordering can do so. > > >> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) > > > Do you mean the send() message should return an (immediate) error when > > the packet is not fit in the outgoing link MTU? But, as Erik > > explained in his reply to Vlad, we cannot always expect the immediate > > error. I admit the spec is a bit complex, but the spec should be > > generic enough (i.e. we cannot assume a particular type of OSes.) > > > => I've read Erik's answer but just try to explain the MTU stuff to > > a common programmer... > > So, what do you want in this section? Are you requiring a change > here? If so, please be more specific. > Would you agree on adding the text similar to Section 6.6 about an additional error message on sendmsg(). The precendence is already set by Section 6.6, but I don't have a very strong opinion on this. > >> - 11.5: is IPV6_REACHCONF really useful (example)? > > > Honestly, I personally do not see a practical usage of this option. > > At least I've never seen an application that uses it. I don't mind to > > remove this, but if any other person wants to keep it, I'll just leave > > the current text as is. The definition has been there since a quite > > old revision of the draft, and it can at least be implemented. > > > => I don't believe the "it can at least be implemented" argument is > > enough to keep something (the opposite is :-). > > Fair enough. Again, I don't mind to drop this section unless someone > wants to keep it. > No strong opinions about this. For most short communications (e.g. UDP) it may not be very usefull (particularly in view of DELAY_FIRST_PROBE_TIME being 5 seconds, so NUD waits a while). For long communications, it probably will not be usefull either. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 12:02:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DK2YFh017574 for ; Wed, 13 Feb 2002 12:02:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DK2YmQ017573 for ipng-dist; Wed, 13 Feb 2002 12:02:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DK2VFh017566 for ; Wed, 13 Feb 2002 12:02:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04300 for ; Wed, 13 Feb 2002 12:02:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28189 for ; Wed, 13 Feb 2002 13:02:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DK2Rk07596; Wed, 13 Feb 2002 21:02:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA05010; Wed, 13 Feb 2002 21:02:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DK2Rg11439; Wed, 13 Feb 2002 21:02:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132002.g1DK2Rg11439@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Thu, 14 Feb 2002 02:55:59 +0900. Date: Wed, 13 Feb 2002 21:02:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Please let me make sure about this comment...are you proposing to > remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper > position of a destination options header (only with the IPV6_DSTOPTS > option)? > => yes > If so, how can a user specify a couple of destination > options headers before and after a routing header? > => he cannot but he doesn't need it and he cannot specify > a destination option header just before a fragmentation header. > IPV6_RTHDRDSTOPTS is unnecessary and misleading. Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's (even "advanced") applications. So I, for one, can live with the single option. However, I'm also quite sure this part is controversial. I'd like to know others opinions... => I expect less objections to simplify things than for the opposite... >> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) > Do you mean the send() message should return an (immediate) error when > the packet is not fit in the outgoing link MTU? But, as Erik > explained in his reply to Vlad, we cannot always expect the immediate > error. I admit the spec is a bit complex, but the spec should be > generic enough (i.e. we cannot assume a particular type of OSes.) > => I've read Erik's answer but just try to explain the MTU stuff to > a common programmer... So, what do you want in this section? Are you requiring a change here? If so, please be more specific. => If there is no proposal for a simpler version, keep it... and be ready to explain it if someone is getting the strange idea to use it (:-). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 12:05:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DK5rFh017591 for ; Wed, 13 Feb 2002 12:05:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DK5r7e017590 for ipng-dist; Wed, 13 Feb 2002 12:05:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DK5kFh017583 for ; Wed, 13 Feb 2002 12:05:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14557; Wed, 13 Feb 2002 12:05:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09513; Wed, 13 Feb 2002 13:05:44 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DK5dk07838; Wed, 13 Feb 2002 21:05:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA05048; Wed, 13 Feb 2002 21:05:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DK5dg11474; Wed, 13 Feb 2002 21:05:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132005.g1DK5dg11474@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Thu, 14 Feb 2002 03:09:01 +0900. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11471.1013630733.1@givry.rennes.enst-bretagne.fr> Date: Wed, 13 Feb 2002 21:05:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I think the philosophical question is deeper. > Knowing the size of IP packets that can be sent without IP fragmentation >... (As a "philosophical" argument) I agree with all the points. But as for the API document, we should (or can) just keep the current text, as Francis agreed in his message. => please keep the current text, we'll see for something else/better for the next revision (the advanced API doesn't need to be perfect, it needs to be published!) Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 12:10:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKA5Fh017608 for ; Wed, 13 Feb 2002 12:10:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DKA56G017607 for ipng-dist; Wed, 13 Feb 2002 12:10:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKA1Fh017600 for ; Wed, 13 Feb 2002 12:10:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09988 for ; Wed, 13 Feb 2002 12:10:03 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11145 for ; Wed, 13 Feb 2002 13:10:02 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA09858; Wed, 13 Feb 2002 12:10:24 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA16507; Wed, 13 Feb 2002 12:10:24 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA02353; Wed, 13 Feb 2002 12:11:40 -0800 (PST) Date: Wed, 13 Feb 2002 12:11:40 -0800 (PST) From: Tim Hartrick Message-Id: <200202132011.MAA02353@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, vlad@zk3.dec.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Cc: Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > > > > Please let me make sure about this comment...are you proposing to > > > remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper > > > position of a destination options header (only with the IPV6_DSTOPTS > > > option)? > > > > > => yes > > > > > If so, how can a user specify a couple of destination > > > options headers before and after a routing header? > > > > > => he cannot but he doesn't need it and he cannot specify > > > a destination option header just before a fragmentation header. > > > IPV6_RTHDRDSTOPTS is unnecessary and misleading. > > > > Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's > > (even "advanced") applications. So I, for one, can live with the > > single option. However, I'm also quite sure this part is > > controversial. I'd like to know others opinions... > > Well, for one, I don't see a good enough reason to remove this. This > particular interface allows the user to specify the header that is discribed > in 2460. Remembering how much discussion (trouble) we all had figuring out > this DO Header stuff, I would leave this particular option there. This > way, anyone trying to use 2460 header ordering can do so. > I have never and still don't see the need to disambiguate between destination options which come before the routing header and those that come after. On the send side it is easy to order your ancillary data or setsockopt calls in a way that gets you what you want. On the receive side, if you one cares whether an option was before or after the routing header one simply needs to receive both destination options and routing headers. Lastly, the current definition requires that at least two passes be made over the options when preparing to deliver ancillary data. This is because IPV6_RTHDRDSTOPTS is defined to be destination options which occur before the routing header. Once can't tell what type of destination options one is delivering until the entire datagram has been passed over to determine whether a routing header is present. All around badness. Unfortunately, we have already been forced to write code that implements this badness. I would welcome the options removal but I don't believe that we should spend a lot of time debating the point. > > > >> - 11.5: is IPV6_REACHCONF really useful (example)? > > > > > Honestly, I personally do not see a practical usage of this option. > > > At least I've never seen an application that uses it. I don't mind to > > > remove this, but if any other person wants to keep it, I'll just leave > > > the current text as is. The definition has been there since a quite > > > old revision of the draft, and it can at least be implemented. > > > > > => I don't believe the "it can at least be implemented" argument is > > > enough to keep something (the opposite is :-). > > > > Fair enough. Again, I don't mind to drop this section unless someone > > wants to keep it. > > > > No strong opinions about this. For most short communications (e.g. UDP) > it may not be very usefull (particularly in view of DELAY_FIRST_PROBE_TIME > being 5 seconds, so NUD waits a while). For long communications, > it probably will not be usefull either. > The only credible argument I have heard in favor of this option what for use with client side NFS over UDP. We have not implemented it yet so I would not miss this option if it disappeared. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 12:59:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKxaFh017919 for ; Wed, 13 Feb 2002 12:59:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DKxaDc017918 for ipng-dist; Wed, 13 Feb 2002 12:59:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKxXFh017911 for ; Wed, 13 Feb 2002 12:59:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22683 for ; Wed, 13 Feb 2002 12:59:36 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02187 for ; Wed, 13 Feb 2002 13:59:35 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id EBD0B35B6; Wed, 13 Feb 2002 15:59:33 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 128A1E9D; Wed, 13 Feb 2002 12:59:33 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DKxUT07061; Wed, 13 Feb 2002 15:59:30 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id PAA0000059910; Wed, 13 Feb 2002 15:59:35 -0500 (EST) Message-ID: <3C6AD3B7.36EF5CE4@zk3.dec.com> Date: Wed, 13 Feb 2002 15:59:35 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" References: <200202132011.MAA02353@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim The IPV6_RTHDRDSTOPTS is a send side only option any more (at least thats how the spec reads). For the recieve side, IPV6_DSTOPTS gets you all the destination options. I guess that might be considered another argument for removing this option... On the other hand, ordering of setsockopt() calls or ancillary data does not necessarily translate into ordering in the packet (however that's one way to implement it). In the end, it's probably easier to keep the option then to remove it, but I can live with either. -vlad Tim Hartrick wrote: > > > I have never and still don't see the need to disambiguate between destination > options which come before the routing header and those that come after. On > the send side it is easy to order your ancillary data or setsockopt calls > in a way that gets you what you want. On the receive side, if you one cares > whether an option was before or after the routing header one simply needs > to receive both destination options and routing headers. Lastly, the current > definition requires that at least two passes be made over the options when > preparing to deliver ancillary data. This is because IPV6_RTHDRDSTOPTS is > defined to be destination options which occur before the routing header. > Once can't tell what type of destination options one is delivering until the > entire datagram has been passed over to determine whether a routing header > is present. All around badness. > > Unfortunately, we have already been forced to write code that implements this > badness. I would welcome the options removal but I don't believe that we > should spend a lot of time debating the point. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 13:29:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DLT3Fh018030 for ; Wed, 13 Feb 2002 13:29:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DLT3pp018029 for ipng-dist; Wed, 13 Feb 2002 13:29:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DLT0Fh018022 for ; Wed, 13 Feb 2002 13:29:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07982 for ; Wed, 13 Feb 2002 13:29:03 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03850 for ; Wed, 13 Feb 2002 14:29:02 -0700 (MST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA15354; Wed, 13 Feb 2002 15:38:07 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA31254; Wed, 13 Feb 2002 15:29:01 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g1DLT1527388; Wed, 13 Feb 2002 15:29:01 -0600 Date: Wed, 13 Feb 2002 15:28:57 -0600 (CST) From: Lilian Fernandes To: cc: Subject: PPP and Global Addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks about the negotiation of the Interface-Identifier and specifies the Interface-Identifier Configuration Option. In this case the upper 64 bits are just fe80:: It does not mention if there is any standard way to configure a global/site-local prefix on a point-to-point link i.e. are there configuration options to let one side tell the other about a global prefix? Or is it just left upto the users at both ends to decide on a prefix somehow and then configure it on each end? I'm sorry if there is an RFC about this that I missed... Thanks, Lilian _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 14:31:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMV4Fh018479 for ; Wed, 13 Feb 2002 14:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMV4hC018478 for ipng-dist; Wed, 13 Feb 2002 14:31:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMV0Fh018471 for ; Wed, 13 Feb 2002 14:31:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10802 for ; Wed, 13 Feb 2002 14:31:02 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02470 for ; Wed, 13 Feb 2002 15:31:01 -0700 (MST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g1DMUekQ007144; Wed, 13 Feb 2002 14:30:40 -0800 (PST) Received: from SIVAV-2000.qualcomm.com (sivav-2000.qualcomm.com [129.46.220.145]) by neophyte.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g1DMUbu4003202; Wed, 13 Feb 2002 14:30:37 -0800 (PST) Message-Id: <4.3.1.2.20020213142140.025f3a70@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 13 Feb 2002 14:30:35 -0800 To: Lilian Fernandes From: Siva Veerepalli Subject: Re: PPP and Global Addresses Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:28 PM 2/13/2002 -0600, Lilian Fernandes wrote: >Hi, > >I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks >about the negotiation of the Interface-Identifier and specifies the >Interface-Identifier Configuration Option. In this case the upper 64 bits >are just fe80:: > >It does not mention if there is any standard way to configure a >global/site-local prefix on a point-to-point link i.e. are there >configuration options to let one side tell the other about a global >prefix? > >Or is it just left upto the users at both ends to decide on a prefix >somehow and then configure it on each end? The prefix is provided using the Route Advertisement Message (see RFC2461). As an aside, I saw a draft on Automatic Prefix Delegation a while back. It talked about providing a router with a prefix it could use to advertise on its attached subnet. It does this using two new ICMPv6 messages. Does anyone know what the status of this draft is? Siva >I'm sorry if there is an RFC about this that I missed... > >Thanks, >Lilian > >_____________________________________________________________________ > >Lilian Fernandes >AIX TCP/IP Development - IBM Austin >Tel: 512-838-7966 Fax: 512-838-3509 > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 14:38:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMccFh018582 for ; Wed, 13 Feb 2002 14:38:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMccO7018581 for ipng-dist; Wed, 13 Feb 2002 14:38:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMcZFh018574 for ; Wed, 13 Feb 2002 14:38:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00098 for ; Wed, 13 Feb 2002 14:38:37 -0800 (PST) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27666 for ; Wed, 13 Feb 2002 14:38:36 -0800 (PST) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA13182; Wed, 13 Feb 2002 16:38:39 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA33452; Wed, 13 Feb 2002 16:38:23 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g1DMcNJ41730; Wed, 13 Feb 2002 16:38:23 -0600 Date: Wed, 13 Feb 2002 16:38:22 -0600 (CST) From: Lilian Fernandes To: Siva Veerepalli cc: , Subject: Re: PPP and Global Addresses In-Reply-To: <4.3.1.2.20020213142140.025f3a70@jittlov.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since PPP does not support multicast, this will involve a smart NDP that takes into consideration the type of interface as well i.e. we cannot send a router solicitation to the all-routers address/send a router advertisement to all-nodes and so on. Is this what most implementations do? I would like to know if most implementations use NDP over PPP in some way. Thanks, Lilian On Wed, 13 Feb 2002, Siva Veerepalli wrote: > At 03:28 PM 2/13/2002 -0600, Lilian Fernandes wrote: > > >Hi, > > > >I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks > >about the negotiation of the Interface-Identifier and specifies the > >Interface-Identifier Configuration Option. In this case the upper 64 bits > >are just fe80:: > > > >It does not mention if there is any standard way to configure a > >global/site-local prefix on a point-to-point link i.e. are there > >configuration options to let one side tell the other about a global > >prefix? > > > >Or is it just left upto the users at both ends to decide on a prefix > >somehow and then configure it on each end? > > The prefix is provided using the Route Advertisement Message (see RFC2461). > > As an aside, I saw a draft on Automatic Prefix Delegation a while back. It > talked about providing a router with a prefix it could use to advertise on > its attached subnet. It does this using two new ICMPv6 messages. Does > anyone know what the status of this draft is? > > Siva > > > >I'm sorry if there is an RFC about this that I missed... > > > >Thanks, > >Lilian > > > >_____________________________________________________________________ > > > >Lilian Fernandes > >AIX TCP/IP Development - IBM Austin > >Tel: 512-838-7966 Fax: 512-838-3509 > > > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 15:13:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DND0Fh018789 for ; Wed, 13 Feb 2002 15:13:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DND0vv018788 for ipng-dist; Wed, 13 Feb 2002 15:13:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DNCvFh018781 for ; Wed, 13 Feb 2002 15:12:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19613 for ; Wed, 13 Feb 2002 15:12:54 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24595 for ; Wed, 13 Feb 2002 16:12:53 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DNCjk22922; Thu, 14 Feb 2002 00:12:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA07595; Thu, 14 Feb 2002 00:12:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DNCig12439; Thu, 14 Feb 2002 00:12:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132312.g1DNCig12439@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Lilian Fernandes cc: ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Wed, 13 Feb 2002 15:28:57 CST. Date: Thu, 14 Feb 2002 00:12:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks about the negotiation of the Interface-Identifier and specifies the Interface-Identifier Configuration Option. In this case the upper 64 bits are just fe80:: => yes, IPv6CP provides only configuration of link-local addresses (for address/prefix/routing). It does not mention if there is any standard way to configure a global/site-local prefix on a point-to-point link i.e. are there configuration options to let one side tell the other about a global prefix? => no, this is done by auto-configuration if one end is a router or by still to be defined protocol (i.e. manual configurtion but look at last interim meeting proceeding where this was discussed) if both ends are router. If no end is router, you don't need more than link-local address... Or is it just left upto the users at both ends to decide on a prefix somehow and then configure it on each end? => this is the current standard solution for the router-to-router case. I'm sorry if there is an RFC about this that I missed... => RFC 2462 "IPv6 Stateless Address Autoconfiguration" (note: on the router side, you can put the prefix configuration in ipv6-up/ipv6-down scripts called when IPv6CP comes up or down. This works very well, usually you even get a race between router advertisement and solicitation so autoconf is always immediate). Regards Francis.Dupont@enst-bretagne.fr PS: http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt (search for Dialup Architecture, note this is my last attempt to find an usefulness to DHCPv6 :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 15:22:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DNMwFh018810 for ; Wed, 13 Feb 2002 15:22:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DNMwPF018809 for ipng-dist; Wed, 13 Feb 2002 15:22:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DNMtFh018802 for ; Wed, 13 Feb 2002 15:22:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22141 for ; Wed, 13 Feb 2002 15:22:57 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29016 for ; Wed, 13 Feb 2002 16:22:56 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DNMjk23888; Thu, 14 Feb 2002 00:22:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA07753; Thu, 14 Feb 2002 00:22:46 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DNMjg12520; Thu, 14 Feb 2002 00:22:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132322.g1DNMjg12520@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Lilian Fernandes cc: Siva Veerepalli , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Wed, 13 Feb 2002 16:38:22 CST. Date: Thu, 14 Feb 2002 00:22:45 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Since PPP does not support multicast, => I disagree: x% uname -sr FreeBSD 4.5-RELEASE x% ifconfig ppp0 ppp0: flags=8010 mtu 1500 ^^^^^^^^^ Is this what most implementations do? => they implement multicast (all of them, I know no exception) Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 16:57:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E0vQFh019026 for ; Wed, 13 Feb 2002 16:57:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E0vQ7C019025 for ipng-dist; Wed, 13 Feb 2002 16:57:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E0vNFh019018 for ; Wed, 13 Feb 2002 16:57:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19101 for ; Wed, 13 Feb 2002 16:57:26 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01334 for ; Wed, 13 Feb 2002 17:57:25 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA04808; Thu, 14 Feb 2002 00:57:12 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Francis Dupont Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses References: <200202132312.g1DNCig12439@givry.rennes.enst-bretagne.fr> From: Ole Troan Date: Thu, 14 Feb 2002 00:57:12 +0000 In-Reply-To: <200202132312.g1DNCig12439@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Thu, 14 Feb 2002 00:12:44 +0100") Message-ID: <7t5ofisswwn.fsf@mrwint.cisco.com> Lines: 48 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks > about the negotiation of the Interface-Identifier and specifies the > Interface-Identifier Configuration Option. In this case the upper 64 bits > are just fe80:: > > => yes, IPv6CP provides only configuration of link-local addresses > (for address/prefix/routing). > > It does not mention if there is any standard way to configure a > global/site-local prefix on a point-to-point link i.e. are there > configuration options to let one side tell the other about a global > prefix? > > => no, this is done by auto-configuration if one end is a router > or by still to be defined protocol (i.e. manual configurtion but > look at last interim meeting proceeding where this was discussed) > if both ends are router. If no end is router, you don't need > more than link-local address... > > Or is it just left upto the users at both ends to decide on a prefix > somehow and then configure it on each end? > > => this is the current standard solution for the router-to-router case. > > I'm sorry if there is an RFC about this that I missed... > > => RFC 2462 "IPv6 Stateless Address Autoconfiguration" > (note: on the router side, you can put the prefix configuration > in ipv6-up/ipv6-down scripts called when IPv6CP comes up or down. > This works very well, usually you even get a race between router > advertisement and solicitation so autoconf is always immediate). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt > (search for Dialup Architecture, note this is my last attempt to find > an usefulness to DHCPv6 :-). we're just about to suggest a couple of new DHCPv6 options for this purpose. http://www.dhcp.org/dhcpv6-23/draft-troan-dhcpv6-opt-prefix-delegation-00.txt /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:21:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3LBFh019829 for ; Wed, 13 Feb 2002 19:21:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3LAK2019827 for ipng-dist; Wed, 13 Feb 2002 19:21:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3L6Fh019816 for ; Wed, 13 Feb 2002 19:21:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13446 for ; Wed, 13 Feb 2002 19:21:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15770 for ; Wed, 13 Feb 2002 20:21:08 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C197@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" Cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:14:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 63 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you're trying to avoid exposing the encryption key, you > can use x, where x is any number that both nodes are > aware of. > > => I don't understand why the peer has to be aware of x. > Do you want to provide QoS inside end nodes? IMHO this is => No, just trying to allow the receiver to verify the value. Nothing to do with QoS > not a bad idea because the CPU is far faster than I/O subsystems, => I guess you meant, "it IS a bad idea" ? :) > BTW most implementations don't provide an API to get the received > flow ID or label, just because this is not considered as useful. => Well, some of us want to. Itojun had draft on this for example. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:21:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3LfFh019843 for ; Wed, 13 Feb 2002 19:21:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Lfrm019842 for ipng-dist; Wed, 13 Feb 2002 19:21:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3LaFh019832; Wed, 13 Feb 2002 19:21:36 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12564; Wed, 13 Feb 2002 19:21:39 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29087; Wed, 13 Feb 2002 19:21:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: How to move forward in the HAO & ingress filter discussion Date: Tue, 15 Jan 2002 13:49:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 546 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? Today's ingress filtering is clearly insufficient for HAO issues. Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? If so, this is too early to discuss, we don't have an agreement on a solution yet. I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, that we need to develop something new to fix the HAO problem 'only sometimes'. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:36:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3aGFh020553 for ; Wed, 13 Feb 2002 19:36:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3aGwg020552 for ipng-dist; Wed, 13 Feb 2002 19:36:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3a9Fh020538 for ; Wed, 13 Feb 2002 19:36:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07040 for ; Wed, 13 Feb 2002 19:36:11 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19485 for ; Wed, 13 Feb 2002 20:36:10 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:b1d3:de73:e644:98ba]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1E3a5o22831; Thu, 14 Feb 2002 12:36:05 +0900 (JST) Date: Thu, 14 Feb 2002 12:34:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <200202132011.MAA02353@feller.mentat.com> References: <200202132011.MAA02353@feller.mentat.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Feb 2002 12:11:40 -0800 (PST), >>>>> Tim Hartrick said: > I have never and still don't see the need to disambiguate between destination > options which come before the routing header and those that come after. On > the send side it is easy to order your ancillary data or setsockopt calls > in a way that gets you what you want. I agree it is (or can be) easy for ancillary data, but I'm not sure about the case of sticky (socket) option. What is your idea in this case? > On the receive side, if you one cares > whether an option was before or after the routing header one simply needs > to receive both destination options and routing headers. Lastly, the current > definition requires that at least two passes be made over the options when > preparing to deliver ancillary data. This is because IPV6_RTHDRDSTOPTS is > defined to be destination options which occur before the routing header. > Once can't tell what type of destination options one is delivering until the > entire datagram has been passed over to determine whether a routing header > is present. All around badness. We've already removed IPV6_RECVRTHDRDSTOPTS and simplified the receive side, so these issues should have gone (although we've lost symmetric semantics between send and receive sides - this can be another motivation to simplify the send side as well). > Unfortunately, we have already been forced to write code that implements this > badness. I would welcome the options removal but I don't believe that we > should spend a lot of time debating the point. I agree. If it is really easy to deal with the send side as you said, it would be the best candidate (so I'd like to know the details). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekG5020843 for ; Wed, 13 Feb 2002 19:40:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VGYa020406 for ipng-dist; Wed, 13 Feb 2002 19:31:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fr020208 for ; Wed, 13 Feb 2002 19:30:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16379 for ; Wed, 13 Feb 2002 19:18:28 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21963 for ; Wed, 13 Feb 2002 20:18:22 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) From: Scott Bradner Message-Id: <200201021922.g02JMSa10173@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Status: RO X-Status: X-Keywords: X-UID: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk all you're saying here is that you don't believe in Intserv/RSVP. I did not say that at all I do not believe that there is currently any way to deal with the *business* and *operational* issues of asking some remote ISP to provide QoS service for you in any sort of scalable way please do not read into what I say any more than I actually say Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3epFh020867 for ; Wed, 13 Feb 2002 19:40:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3eoYO020864 for ipng-dist; Wed, 13 Feb 2002 19:40:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0G3020775 for ; Wed, 13 Feb 2002 19:39:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12270 for ; Wed, 13 Feb 2002 19:17:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14607 for ; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 08:42:09 -0500 (EST) From: Scott Bradner Message-Id: <200201021342.g02Dg9Q08853@newdev.harvard.edu> To: brian@hursley.ibm.com, perry@wasabisystems.com Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com, mat@cisco.com Status: RO X-Status: X-Keywords: X-UID: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian sez: > In the intserv case, it is no different. In the diffserv case, the presumption > is that we would use IANA-assigned, globally meaningful values, that are > specific to a desired QOS treatment rather than to any individual traffic flow. > The implementation details (including the DSCP value and router configurations) > may differ from ISP to ISP, but the flow label bits convey end to end > semantics. This is more powerful than port numbers whose semantics are poor at > best for QOS purposes, and it works when the port numbers are invisible. this still begs the question why do folk think that ISPs half way around the world would find it useful to know what the sending computer wanted for QoS? at least in the case of difserv if an ISP gets a DSCP there is some implied authorization by the previous network (ISP or enterprise) - how does authorization happen in the case of imutable globally meaningful values? I see no reason to believe that such a field will be any use whatsoever in providing QoS in the Internet - and it is redundant in an enterprise because the enterprise can decide to not change the DSCP field unless there is some hint of a way for this change to serve any useful purpose we should just leave things as they are Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGF020843 for ; Wed, 13 Feb 2002 19:40:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jswo019803 for ipng-dist; Wed, 13 Feb 2002 19:19:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HxFh019560; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04629; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02352; Wed, 13 Feb 2002 19:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Fri, 4 Jan 2002 17:57:13 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 131 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 4 Jan 2002, Francis Dupont wrote: > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). Feedback you get here does *not* reflect to the real world -- those who work around here, are usually even a little conscientious. The problem is the ignorant and the uncaring. FWIW, we provide connectivity for every university and the like in Finland, and they're all ingress-filtered at ISP-organization border. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGZ020843 for ; Wed, 13 Feb 2002 19:40:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jh0E019783 for ipng-dist; Wed, 13 Feb 2002 19:19:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I4Fh019597 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04640 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02364 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.2.2.20020103144313.045caa60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Jan 2002 14:51:00 -0500 To: george+ipng@m5p.com From: Margaret Wasserman Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200201031901.g03J1fJu057738@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO X-Status: X-Keywords: X-UID: 94 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi George, Yes, we are "humming" in agreement to the proposal that we replace section 6 of RFC 2460 with the following text: > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > And that we delete Appendix A from RFC 2460. Actually, we probably won't update RFC 2460. We'll probably just publish a separate RFC that updates 2460. Margaret At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: >Just a quick question from an interested lurker: Are these hums of >acquiescence in response, specifically, to the idea that an originating >node may set the flow label to any value, and that nodes forwarding >packets will leave that value alone? -- George Mitchell > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGN020843 for ; Wed, 13 Feb 2002 19:40:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3V4No020401 for ipng-dist; Wed, 13 Feb 2002 19:31:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fp020208 for ; Wed, 13 Feb 2002 19:30:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16277 for ; Wed, 13 Feb 2002 19:18:14 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13569 for ; Wed, 13 Feb 2002 20:18:13 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020109133527.0369add0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:38:35 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: DHC WG last call for DHCPv6 Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 325 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you've reviewed the most recent rev of the DHCPv6 spec , please post your comments to dhcwg@ietf.org - even if your comments are as brief as "looks ready for submission for Proposed Standard"... - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekG1020843 for ; Wed, 13 Feb 2002 19:40:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VDMs020405 for ipng-dist; Wed, 13 Feb 2002 19:31:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fn020208 for ; Wed, 13 Feb 2002 19:30:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16296 for ; Wed, 13 Feb 2002 19:18:16 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28080 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 15:26:01 -0500 (EST) From: Scott Bradner Message-Id: <200201022026.g02KQ1v10554@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Status: RO X-Status: X-Keywords: X-UID: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we can easily reserve a few bits and state that the flow label only applies when the reserved bits ignored. as I said, I'm fine with the suggested wording but I don;t think that the base doc should say anything else having an experimental rfc that talks about ways to use the bits seems a reasonable thing also Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGv020843 for ; Wed, 13 Feb 2002 19:41:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VN8k020409 for ipng-dist; Wed, 13 Feb 2002 19:31:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GB020208 for ; Wed, 13 Feb 2002 19:30:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16308 for ; Wed, 13 Feb 2002 19:18:17 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07102 for ; Wed, 13 Feb 2002 20:18:16 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C3DA086.CC6FB497@hursley.ibm.com> Date: Thu, 10 Jan 2002 15:09:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 357 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? You can't, any more than you can be sure the DSCP hasn't changed, or that somebody isn't playing games with port numbers to fool your classifier. The ISP's defence against this is that more QoS will result in a higher bill. So the ISP actually doesn't care; they get paid accordingly. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGR020843 for ; Wed, 13 Feb 2002 19:40:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3UoUu020385 for ipng-dist; Wed, 13 Feb 2002 19:30:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fl020208 for ; Wed, 13 Feb 2002 19:30:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16124 for ; Wed, 13 Feb 2002 19:18:02 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06986 for ; Wed, 13 Feb 2002 20:18:00 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> <3C3586EE.9B8D002A@hursley.ibm.com> Message-Id: Date: Fri, 04 Jan 2002 07:35:50 -0800 Status: RO X-Status: X-Keywords: X-UID: 126 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And, truth in advertising, we have heard two dissenting > views: > > a) that the field should be defined as MUST BE ZERO, i.e. > the MAY clause below gets deleted fwiw, i withdraw my dissent randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGD020843 for ; Wed, 13 Feb 2002 19:40:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3UwNc020398 for ipng-dist; Wed, 13 Feb 2002 19:30:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Ft020208 for ; Wed, 13 Feb 2002 19:30:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16152 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13477 for ; Wed, 13 Feb 2002 20:18:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201081705.g08H5gQ21789@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: draft-goswami-ipv6-discovery-link-option-00.txt Date: Tue, 08 Jan 2002 18:05:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 272 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is this a joke or the notion of padding so obscure? RFC 2529 (aka 6over4) is an example of a link-layer address which is not 6+8*n, RFC 2492 (IPv6 over ATM) is an example of a complex and variable length link-layer address format in neighbor discovery extension! Francis.Dupont@enst-bretagne.fr PS: fortunately I am not in the acknowledgment section (:-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGd020843 for ; Wed, 13 Feb 2002 19:40:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Vb7Q020419 for ipng-dist; Wed, 13 Feb 2002 19:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GD020208 for ; Wed, 13 Feb 2002 19:30:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16195 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14685 for ; Wed, 13 Feb 2002 20:18:05 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201090301.g0931mg22742@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Tue, 8 Jan 2002 19:01:48 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Re: Question on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [147.11.38.42] X-Mailer: Speakeasy Network Webmail 2.1.0 Status: RO X-Status: X-Keywords: X-UID: 287 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 08 Jan 2002, Qing Li wrote: > >If the router participates in multiple > >routing domains then this table should > >contain routing info from multiple routing > >tables, is that so? > > If I understand your question, > ipCidrRouteTable already shows the origin of a > route installed in the FIB, see > ipCidrRouteProto. > My question was incorrectly worded. I meant to say if the ipCidrRouteTable represents the RIB then does that imply this table is the conglomeration of all the RIBs of the participated routing protocols. Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHF020843 for ; Wed, 13 Feb 2002 19:41:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JoQl019799 for ipng-dist; Wed, 13 Feb 2002 19:19:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HvFh019539 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11598 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13375 for ; Wed, 13 Feb 2002 20:17:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C196@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:08:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, [ Sorry catching up on old emails] > >come back to basics and say that the flow label > >is part of the IPv6 header, therefore it seems > >rational to let IPv6 WG define its use. > >I don't see anything wrong with this, no other > >fields in the IPv6 header are defined by other > >groups. > > This is acceptable to me, if it represents a consensus view > of the WG. But, in this case, we should go all the way > and actually specify a useful flow label -- one that > could be used to look-up cached information on intermediate > routers without a signalling protocol, for example. => OK, so what you're saying is that it's ok to have an immutable flow label but we should not have to mandate signalling to install the value in routers. That's also fine with me. What that means to me is that we can have some of the FL values reserved for assignment by IANA, provided we maintain immutability. Ie. using IANA as a signalling protocol :) I'm ok with that, but I know some (a lot ?) of people don't agree with it. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHZ020843 for ; Wed, 13 Feb 2002 19:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e3ri020830 for ipng-dist; Wed, 13 Feb 2002 19:40:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGF020453 for ; Wed, 13 Feb 2002 19:38:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04873 for ; Wed, 13 Feb 2002 19:18:41 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13808 for ; Wed, 13 Feb 2002 20:18:40 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1C2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" , Francis Dupont Cc: Jari Arkko , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Wed, 9 Jan 2002 18:54:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 322 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, Just catching up on this thread, a couple of questions below. > So here's a most-likely crazy idea: why can't we > treat the ingress filtering router like a CN which > must first be sent a BU which it verifies in > whatever manner the CN would? This already has a > requirement to not be bound to mythical PKI's, > etc. Given FMIP, the access routers are probably > going to end up having to process things like BU's > anyway. => Let me understand what this would do: what happens after the MN sends a BU ? Does the default router look though each packet to verify the HAO ? > > Also: if we have ingress filtering taken care of > directly, is there any reason to preserve the HAO > at all? I thought its entire raison d'etre was to > provide a means of coexisting with ingress > filtering -- => Well, no, it is a form of tunnelling, (combined with RH) if you remove it you'd have to tunnel right ? I feel like I misunderstood a few things in your text. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekG7020843 for ; Wed, 13 Feb 2002 19:40:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3V7cL020403 for ipng-dist; Wed, 13 Feb 2002 19:31:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fj020208 for ; Wed, 13 Feb 2002 19:30:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16233 for ; Wed, 13 Feb 2002 19:18:11 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21876 for ; Wed, 13 Feb 2002 20:18:10 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 13:14:36 -0500 (EST) From: Scott Bradner Message-Id: <200201021814.g02IEad09837@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, moore@cs.utk.edu, perry@wasabisystems.com Status: RO X-Status: X-Keywords: X-UID: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are you claiming that RFC 3182 (nee 2752) is inadequate for interdomain? for telling someone who you are its fine but that does not even start to address teh operational issues of how an ISP would make use of the information Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekG9020843 for ; Wed, 13 Feb 2002 19:40:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VgUJ020425 for ipng-dist; Wed, 13 Feb 2002 19:31:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GN020208 for ; Wed, 13 Feb 2002 19:30:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16151 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07007 for ; Wed, 13 Feb 2002 20:18:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Tue, 08 Jan 2002 10:52:03 -0600 From: Matt Crawford Subject: Re: I-D ACTION:draft-goswami-ipv6-discovery-link-option-00.txt In-reply-to: "08 Jan 2002 08:46:19 EST." <200201081346.IAA20693@ietf.org> To: ipng@sunroof.eng.sun.com Message-id: <200201081652.g08Gq3l06548@gungnir.fnal.gov> Status: RO X-Status: X-Keywords: X-UID: 270 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm afraid I don't get it. The proposed new option does nothing the existing source/target link layer options don't do. On a medium "foonet" with a variable length link-layer address, you'd have to encode the length of the address in the link-layer address field either way. (Actually, I'd imagine the length would be likely to be self-encoding, but that's irrelevant.) You can specify it in your ipv6-over-foonet document. Unless you're envisioning some new way to transmit frames over an existing physical layer with new address formats ...? And I assume this is a typo of some sort: Length The length of the option (including the type and length fields) in units of 1/8 th octets. Forexample, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHB020843 for ; Wed, 13 Feb 2002 19:41:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JH0D019760 for ipng-dist; Wed, 13 Feb 2002 19:19:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HqFh019495; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12180; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13356; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGV020843 for ; Wed, 13 Feb 2002 19:40:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PsR0020101 for ipng-dist; Wed, 13 Feb 2002 19:25:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFr019898 for ; Wed, 13 Feb 2002 19:24:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12260 for ; Wed, 13 Feb 2002 19:18:58 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22299 for ; Wed, 13 Feb 2002 20:18:57 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201231602.g0NG2er04675@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: irinadayal@netscape.net (Irina Dayal) cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Wed, 23 Jan 2002 09:33:08 EST." <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> Date: Wed, 23 Jan 2002 11:02:40 -0500 Status: RO X-Status: X-Keywords: X-UID: 912 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits > long? no. because nothing requires a site to use the lower 64 bits as an interface ID - a site is free to subnet that space if it wishes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekG3020843 for ; Wed, 13 Feb 2002 19:40:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Pqm9020098 for ipng-dist; Wed, 13 Feb 2002 19:25:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGP019898 for ; Wed, 13 Feb 2002 19:24:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12202 for ; Wed, 13 Feb 2002 19:18:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02724 for ; Wed, 13 Feb 2002 19:18:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 23 Jan 2002 09:33:08 -0500 From: irinadayal@netscape.net (Irina Dayal) To: ipng@sunroof.eng.sun.com Subject: IPv6 Addr/Prefix clarification Message-ID: <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Status: RO X-Status: X-Keywords: X-UID: 891 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am new here so please excuse the trivial questions. I did trawl the archives but could not find a definitive answer. 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long? The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast Addresses, which restricts the prefixes to this range. 2) Is it possible for two hosts with the same interface ID (lower 64 bits) to have different prefixes (upper 64 bits) in their addresses? The v6 standards indicate that the interface ID does not always have global scope, so the answer appears to be yes. Thank you for reading... Irina -- __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekH9020843 for ; Wed, 13 Feb 2002 19:41:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jp5k019801 for ipng-dist; Wed, 13 Feb 2002 19:19:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HvFh019551 for ; Wed, 13 Feb 2002 19:17:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12194 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14569 for ; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Sat, 29 Dec 2001 00:56:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: '::' address as destination To: Lilian Fernandes Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hello, > > RFC 2373 states that: > "The unspecified address must not be used as the destination address > of IPv6 packets or in IPv6 Routing Headers." > > However it seems that certain stacks are using this address in a different > way. Yes, but I don't think there is an inherent conflict. RFC 2373 specifies the behavior on the wire i.e. what is carried in IPv6 packets. Implementations might do various things at the API interface, but the an implementation should ensure and :: doesn't appear as the destination in the IPv6 packets it sends. > When '::' is the destination address: > - some use the first available interface's address > - some use the loopback address > > Is there a chance that one of these will become the acceptable norm? It > would be interesting to know if the majority of implementations actually > return an error for this case. I know that for Solaris we interpret :: at the API as the loopback address. This was done to be consistent with the IPv4 Solaris code. Unfortunately the introduction of the mechanism in the IPv4 Solaris code was before my time. I don't think it existed in BSD 4.3tahoe but I haven't checked. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekH3020843 for ; Wed, 13 Feb 2002 19:41:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q3JR020108 for ipng-dist; Wed, 13 Feb 2002 19:26:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGZ019898 for ; Wed, 13 Feb 2002 19:25:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12258 for ; Wed, 13 Feb 2002 19:18:58 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22298 for ; Wed, 13 Feb 2002 20:18:57 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201231558.g0NFw7g04149@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: irinadayal@netscape.net (Irina Dayal) cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of Wed, 23 Jan 2002 09:33:08 EST. <5ED04AD8.3ED557E2.0F7DF3AA@netscape.net> Date: Wed, 23 Jan 2002 16:58:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 898 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long? The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast Addresses, which restricts the prefixes to this range. => if this seems to be safe today you may *not* assume this will remain safe in the future, conclusion: this is not safe. 2) Is it possible for two hosts with the same interface ID (lower 64 bits) to have different prefixes (upper 64 bits) in their addresses? The v6 standards indicate that the interface ID does not always have global scope, so the answer appears to be yes. => yes, I know at least 10 boxes with the 1 interface ID and near the same number with 2. But I believe there are hundreds or thousands... (BTW only a small fraction of them are hosts (i.e. not routers)) Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGH020843 for ; Wed, 13 Feb 2002 19:40:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dGhZ020801 for ipng-dist; Wed, 13 Feb 2002 19:39:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFj020453 for ; Wed, 13 Feb 2002 19:38:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04643 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14593 for ; Wed, 13 Feb 2002 20:17:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201031951.g03JpUi15349@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: george+ipng@m5p.com cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 11:01:41 PST." <200201031901.g03J1fJu057738@m5p.com> Date: Thu, 03 Jan 2002 14:51:30 -0500 Status: RO X-Status: X-Keywords: X-UID: 93 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just a quick question from an interested lurker: Are these hums of > acquiescence in response, specifically, to the idea that an originating > node may set the flow label to any value, and that nodes forwarding > packets will leave that value alone? -- George Mitchell not quite. if we someday define how the flow label is to be used, originating nodes can follow that spec. that's not the same thing as saying that originating nodes can set the flow label field to whatever value they like. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIR020843 for ; Wed, 13 Feb 2002 19:41:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e5vN020833 for ipng-dist; Wed, 13 Feb 2002 19:40:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGh020453 for ; Wed, 13 Feb 2002 19:39:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04846 for ; Wed, 13 Feb 2002 19:18:39 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22120 for ; Wed, 13 Feb 2002 20:18:37 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.17973.145302.745873@thomasm-u1.cisco.com> Date: Fri, 11 Jan 2002 12:08:21 -0800 (PST) To: "Steven M. Bellovin" Cc: Brian E Carpenter , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <20020111150246.D34077B4B@berkshire.research.att.com> References: <20020111150246.D34077B4B@berkshire.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Status: RO X-Status: X-Keywords: X-UID: 418 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin writes: > In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E Carpenter writes: > >Indeed. All of this is the same for the DSCP actually, and the > >assumption is that operators will protect themselves with > >admission control. > > > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) > > > > Right. The question now is how to do that. I was about to agree > strongly with the "must send as zero if not a flow, routers must not modify" > until I started thinking along these lines. What should a border > router do with a packet that doesn't meet its constraints? I only see > three choices: reset the flow label to something locally acceptable, > drop the packet, or tunnel. But dropping the packet means that flow > labels can only be used for flows that stay within a particular flow > label domain, and the tunneling path leads to madness. (Well, perhaps > to MPLS, but I don't think we want to go down that rathole now.) I'm > forced to conclude that we have two choices: either we give up on flow > labels entirely, or we permit them to be modified en route. First of all, there's nothing that is defined from which to take action based on the flow label, so I think this is largely an academic question. If we suspend some disbelief and posit an edge device which, say, polices a flow to a particular rate, why does it follow that the router would need the ability to rewrite the label? Certainly in the Intserv case, policers don't rewrite the 5 tuple. Their only option is to change the PHB or drop it. In diffserv style, it can in addition to dropping and changing its queuing characteristics, rewrite the DSCP. So I guess I just don't see where a policer would need the ability to alter it. Also: pragmatically, we can alway change our mind on the mutability front if it starts life as *immutable*. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHl020843 for ; Wed, 13 Feb 2002 19:41:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Ve78020421 for ipng-dist; Wed, 13 Feb 2002 19:31:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GR020208 for ; Wed, 13 Feb 2002 19:30:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16393 for ; Wed, 13 Feb 2002 19:18:28 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14844 for ; Wed, 13 Feb 2002 20:18:27 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201081110.g08BAWQ18568@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 12:48:35 +0200. Date: Tue, 08 Jan 2002 12:10:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 263 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => as multi-homing is a place we could want to use home address options > this is a real issue... I've always thought using Home Address option as a way of getting around ingress filtering checks in multihoming is like "if words fail you, mumble!" -approach. => I agree if it is only a way of getting around ingress filtering checks but there are some situations where to have more than one source address is very fine. And don't forget the degenerate tunneling argument. Much more analysis is needed IMO before HAO is to be used outside of MIPv6 context. => yes and to provide an independent and complete definition of HAO should be very useful too. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHn020843 for ; Wed, 13 Feb 2002 19:41:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e40U020831 for ipng-dist; Wed, 13 Feb 2002 19:40:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGV020453 for ; Wed, 13 Feb 2002 19:38:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05000 for ; Wed, 13 Feb 2002 19:18:50 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15032 for ; Wed, 13 Feb 2002 20:18:49 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Mon, 21 Jan 2002 09:51:20 -0500 From: Nathan Lutchansky To: Ramakrishnan Cc: ipng@sunroof.eng.sun.com Subject: Re: Query About MLD Message-ID: <20020121095120.A2431@litech.org> References: <20020121123505.22487.qmail@mailFA8.rediffmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121123505.22487.qmail@mailFA8.rediffmail.com>; from rama_krishnans@rediffmail.com on Mon, Jan 21, 2002 at 12:35:05PM -0000 Status: RO X-Status: X-Keywords: X-UID: 815 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2002 at 12:35:05PM -0000, Ramakrishnan wrote: > Why MLD ( Multicast Listener Discovery) message are sent for Sloicited-No= de > multicast address ? Intelligent link-layer devices like Ethernet switches may snoop the MLD pac= kets to=20 learn what multicast addresses each device is listening to. In the absence= of MLD=20 packets, switches would need to flood all multicast packets to the whole ne= twork,=20 because there is no way of knowing which devices want which packets. -Nath= an --=20 +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TCroTviDkW8mhycRAgmbAKCoS9drSWPY1LaG4eNNZ0RnVA7vxwCfZPaC +8IoczXTX60ilQBOuGS/YZA= =JhlN -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHf020843 for ; Wed, 13 Feb 2002 19:41:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JNYW019771 for ipng-dist; Wed, 13 Feb 2002 19:19:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HrFh019507 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12186 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02340 for ; Wed, 13 Feb 2002 19:17:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.2.2.20020103112950.045b4320@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Jan 2002 11:31:14 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C348636.DB130121@hursley.ibm.com> References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO X-Status: X-Keywords: X-UID: 68 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So, I think it's time for a hum on this one (the simple >update to 2460 that Scott and I at least seem to agree >on). Hum. Could someone publish an internet draft with this wording? The only draft that we have now is pretty far away from this. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGX020843 for ; Wed, 13 Feb 2002 19:40:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JEi2019759 for ipng-dist; Wed, 13 Feb 2002 19:19:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I8Fh019637 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12258 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13410 for ; Wed, 13 Feb 2002 20:17:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> Message-Id: Date: Wed, 02 Jan 2002 12:36:59 -0800 Status: RO X-Status: X-Keywords: X-UID: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I do not believe that there is currently any way to deal with the >> *business* and *operational* issues of asking some remote ISP >> to provide QoS service for you in any sort of scalable way > Fine, but that's completely orthogonal to whether the flow label is > a good idea or not. we don't care that no one can operationally use it. if it might sell one more router, let's kludge up the net a bit more. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHR020843 for ; Wed, 13 Feb 2002 19:41:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jbw4019779 for ipng-dist; Wed, 13 Feb 2002 19:19:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HpFh019494 for ; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11571 for ; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13347 for ; Wed, 13 Feb 2002 20:17:51 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C348636.DB130121@hursley.ibm.com> Date: Thu, 03 Jan 2002 17:26:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 66 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The one acronym summary of kre's point is: SLA. I'd venture to say that no QoS solution will ever work in the absence of an SLA. And guess what, the IETF doesn't discuss business models and SLAs. The most we can do is standardise tools that can be deployed to support SLAs. So, I think it's time for a hum on this one (the simple update to 2460 that Scott and I at least seem to agree on). Brian Robert Elz wrote: > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > From: Scott Bradner > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > | I do not believe that there is currently any way to deal with the > | *business* and *operational* issues of asking some remote ISP > | to provide QoS service for you in any sort of scalable way > > Yes, that's a real hard problem. But it isn't the current one. > > There are two separate issues here - how to communicate the information, > and then how to use it. > > Now it is certainly true that communicating information is a waste of time > if the information can't be used -- but it is also true that there's no > point figuring out how to use the information if there's no way to communicate > it. > > Since the operational issues are hard, without doubt, there's a certain > reluctance to attempt to find a solution to it - and as long as that can > be avoided by resorting to "we don't need it yet, there'd be no way to use > it anyway", that is what will keep happening. > > But there is a simple solution which can arise - I, as a customer, can work > out what path my packets will take (AS path), make contact with all of the > ISPs represented, and offer to pay them large amounts of cash to make some > specific set of my packets get to some particular destination(s) much more > reliably with much lower than normal (congested) delay. That's easy to do > (assuming the availability of the cash). It can be done today. > > However, assuming I do that, how are all those ISPs supposed to implement > my request? Currently they'd have to do it using port number snooping, > and so I'd have to be able to specify the port numbers in advance. But > that's not always possible, nor is it a rational design in any case (it > just happens to be all that's probably possible with IPv4). With IPv6 > I can simply arrange to label all the "important" packets, so all those > ISPs, who are only too willing to accept the cash, can actually manage to > earn it. > > Now of course, as an operational method, the one above doesn't scale at all. > But that's OK, it doesn't have to - it isn't being proposed as a method > to be adopted by all and sundry. What it has done is provided the > motivation for the mechanism to exist that allows the packet classification > to be reasonable. Given that, the desire to make use of this will grow, > and the operational community will be forced to do the work to figure out > how to make it feasible economically. > > This may end up falling back to explicit agreements between sender > (or receiver) of the data and everyone along the path (as in a credit > card number included in the RSVP reservation packet, or the equivalent) > Or it could be done based on settlements between ISPs, with the ISPs > perhaps using the DSCP in packets passing between them to indicate: > "I am being paid more to achieve better results for this packet, it will > offset as more than a normal packet if you also give it priority" with > most likely, each ISP subtracting a little from the amount offered as > their own compensation, so the sender would need to offer more to get > priority through a long path than through a short one (which is entirely > reasonable). Or it could be something quite different. > > I don't think it is for this working group to answer that question. > I do think it is reasonable though for enough basic mechanism to be > provided that the ISPs can actually process the packets reasonably > though - and I think now that we know enough about how the protocol > parts of all this can be made to work (as aside from the operational > issues) that it can be done now - and so provide the rationale for > actually doing the operational work. > > Chasing down header chains looking for a transport header certainly > isn't the answer (even considering ESP headers as transport for this > purpose, which I'm not sure I'd regard as correct anyway). Unlike > in IPv4, there's no guarantee that the transport header will even occur > in the first fragment of a large packet in IPv6. While it might seem to > be folly to send fragmented packets at the IP level and expect any kind > of quality of service, with IPv6 it really isn't. If the amount of > data that has to be delivered (whether that be transport data, or > additional data from extra "headers" is larger) than will fit across the > path MTU, then some kind of fragmentation is required. Whether that's > done at the IPv6 layer, or at the transport layer (with some kind of > segmented messages) doesn't really make any difference - all the pieces > need to arrive for the data to be interpreted (that's an assumption). > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > And if that's done, the port numbers (or even ESP SPI) might not be in > the first fragment. This cannot disqualify the packet from receiving > any kind of QoS treatment. With IPv6 there is no need for it to do so > either - everything needed to classify the packet is in the IPv6 header > (addresses and flow label). That's all routers should be looking at, as > it is all that they can reliably expect to actually find (even ignoring the > issue of "find quickly"). > > kre -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGp020843 for ; Wed, 13 Feb 2002 19:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Vjwa020427 for ipng-dist; Wed, 13 Feb 2002 19:31:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Gb020208 for ; Wed, 13 Feb 2002 19:30:37 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16272 for ; Wed, 13 Feb 2002 19:18:14 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28100 for ; Wed, 13 Feb 2002 19:18:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Randy Bush Cc: Keith Moore , Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 12:34:07 -0500 Message-Id: <20020103173407.D319C7B55@berkshire.research.att.com> Status: RO X-Status: X-Keywords: X-UID: 74 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Randy Bush writes: >>> The proposed new words for 2460 effectively say >>> - you don't have to set it >>> - you don't have to look at it >>> - you mustn't change it >>> I don't think encourages kludge significantly more than MBZ text, but it >>> does allow for future usage. >> as I see it, the proposed words let us get Flow Label off our >> plates for now, which is good because we don't know what to do >> with it anyway. maybe someday someone wall make a convincing >> case for how to use it. > >and, if we do mbz, they can then write the rfc which changes that The problem then is all the implementations -- or firewalls -- that will check that the bits really are zero upon receipt. If you want MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT check". Then you have to hope that folks listen to that part. Especially for firewalls, I wouldn't count on that. (For precedent, so to speak, look at what happened with the ECN bits when a particular version of Linux started using them.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGh020843 for ; Wed, 13 Feb 2002 19:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PeWH020086 for ipng-dist; Wed, 13 Feb 2002 19:25:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXG1019898 for ; Wed, 13 Feb 2002 19:24:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11856 for ; Wed, 13 Feb 2002 19:18:16 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13581 for ; Wed, 13 Feb 2002 20:18:15 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201071033.g07AXNr20081@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Mon, 7 Jan 2002 02:33:23 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Ques. on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [64.81.55.94] X-Mailer: Speakeasy Network Webmail 2.1.0 Status: RO X-Status: X-Keywords: X-UID: 431 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The last sentence in the description for "inetCidrRouteAge" states "....except through knowledge of the routing protocol by which the route was learned." Does that mean "inetCidrRouteAge" applies to entries with "inetCidrRouteProto" in the range of 5 - 16 as stated in rfc2096? Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGJ020843 for ; Wed, 13 Feb 2002 19:40:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3J3f4019748 for ipng-dist; Wed, 13 Feb 2002 19:19:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HrFh019513 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12191 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14571 for ; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <20020103173407.D319C7B55@berkshire.research.att.com> Message-Id: Date: Thu, 03 Jan 2002 09:37:13 -0800 Status: RO X-Status: X-Keywords: X-UID: 76 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> and, if we do mbz, they can then write the rfc which changes that > The problem then is all the implementations -- or firewalls -- that > will check that the bits really are zero upon receipt. If you want > MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT > check". as i thought it was the stated mbz formulation, i was assuming this. > Then you have to hope that folks listen to that part. Especially for > firewalls, I wouldn't count on that. (For precedent, so to speak, look > at what happened with the ECN bits when a particular version of Linux > started using them.) hmmm. i think i am starting to reconsider. idiots are soooo creative. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHh020843 for ; Wed, 13 Feb 2002 19:41:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VX4L020416 for ipng-dist; Wed, 13 Feb 2002 19:31:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GL020208 for ; Wed, 13 Feb 2002 19:30:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16677 for ; Wed, 13 Feb 2002 19:18:49 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22224 for ; Wed, 13 Feb 2002 20:18:48 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: Brian E Carpenter cc: "Steven M. Bellovin" , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C46B954.4B0A1500@hursley.ibm.com> References: <3C46B954.4B0A1500@hursley.ibm.com> <20020111150246.D34077B4B@berkshire.research.att.com> <5847.1011016992@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 12:55:58 +0700 Message-ID: <3819.1011333358@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 721 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Jan 2002 12:45:24 +0100 From: Brian E Carpenter Message-ID: <3C46B954.4B0A1500@hursley.ibm.com> | In any case, the behaviour when you see an "unknown" flow label should be | the same as when you see a zero label - apply default treatment, whatever | that happens to be locally. No need to either drop the packet or | rewrite the label; at that point it's just a noise field. Yes, of course. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGr020843 for ; Wed, 13 Feb 2002 19:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dqcM020820 for ipng-dist; Wed, 13 Feb 2002 19:39:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGN020453 for ; Wed, 13 Feb 2002 19:38:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04812 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13777 for ; Wed, 13 Feb 2002 20:18:35 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 17 Jan 2002 16:28:06 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Status: RO X-Status: X-Keywords: X-UID: 647 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Jan 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > I agre with Francis. And, actually, our implementation (i.e. all *BSD > variants) basically keeps the same router (of the same priority), so > it will be non-compliant with the SHOULD. I believe our > implementation is not the only example of this "non-compliant" behavior. True. > If the SHOULD is really the consensus, I'll change the implementation > so that it will be compliant again. However, I'm still not fully > convinced that the change is worth making (perhaps many) existing > applications non-compliant. > > As Francis pointed out, there are many cases of "several default > routers with a better one." In this case, picking up random routers > (without the knowledge of router preference) will just be meangless, > because we'll eventually converge on the better router with redirect > messages. I agree, as I commented on this when the draft first appeared. IMO it's _much_ better practise have predictable behaviour. Load-distribution is not that. When there are two default routes of equal weight, I want to only use one, and if the one I use fails, failover nicely to the other. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHD020843 for ; Wed, 13 Feb 2002 19:41:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Ji3e019785 for ipng-dist; Wed, 13 Feb 2002 19:19:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I9Fh019640 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12264 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02369 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C3586EE.9B8D002A@hursley.ibm.com> Date: Fri, 04 Jan 2002 11:41:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: george+ipng@m5p.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 119 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And, truth in advertising, we have heard two dissenting views: a) that the field should be defined as MUST BE ZERO, i.e. the MAY clause below gets deleted b) that the 3rd MUST should be SHOULD, i.e. immutability should be default instead of mandatory. Brian Margaret Wasserman wrote: > > Hi George, > > Yes, we are "humming" in agreement to the proposal that we > replace section 6 of RFC 2460 with the following text: > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > And that we delete Appendix A from RFC 2460. > > Actually, we probably won't update RFC 2460. We'll probably > just publish a separate RFC that updates 2460. > > Margaret > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > >Just a quick question from an interested lurker: Are these hums of > >acquiescence in response, specifically, to the idea that an originating > >node may set the flow label to any value, and that nodes forwarding > >packets will leave that value alone? -- George Mitchell > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGB020843 for ; Wed, 13 Feb 2002 19:40:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Pp9Z020097 for ipng-dist; Wed, 13 Feb 2002 19:25:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFt019898 for ; Wed, 13 Feb 2002 19:24:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11791 for ; Wed, 13 Feb 2002 19:18:08 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13499 for ; Wed, 13 Feb 2002 20:18:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 11:20:45 -0500 (EST) From: Scott Bradner Message-Id: <200201021620.g02GKju09321@newdev.harvard.edu> To: moore@cs.utk.edu, sob@harvard.edu Subject: Re: Flow Label Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Status: RO X-Status: X-Keywords: X-UID: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > why do folk think that ISPs half way around the world would find it useful > > to know what the sending computer wanted for QoS? > because the sending computer (application) knows the nature of the traffic? without a way for the remote ISP to get paid for treating the traffic in some way other then best-effort I do not see that this helps Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGl020843 for ; Wed, 13 Feb 2002 19:41:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dOao020811 for ipng-dist; Wed, 13 Feb 2002 19:39:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFl020453 for ; Wed, 13 Feb 2002 19:38:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04662 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07058 for ; Wed, 13 Feb 2002 20:18:08 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201031709.g03H9ii13070@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Randy Bush , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 17:18:58 +0100." <3C348472.DD2BE3C9@hursley.ibm.com> Date: Thu, 03 Jan 2002 12:09:43 -0500 Status: RO X-Status: X-Keywords: X-UID: 71 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Randy, > > The proposed new words for 2460 effectively say > - you don't have to set it > - you don't have to look at it > - you mustn't change it > > I don't think encourages kludge significantly more than MBZ text, but it > does allow for future usage. as I see it, the proposed words let us get Flow Label off our plates for now, which is good because we don't know what to do with it anyway. maybe someday someone wall make a convincing case for how to use it. for now, other things are probably more worthy of attetion. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGt020843 for ; Wed, 13 Feb 2002 19:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PYYW020085 for ipng-dist; Wed, 13 Feb 2002 19:25:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFp019898 for ; Wed, 13 Feb 2002 19:24:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12008 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13710 for ; Wed, 13 Feb 2002 20:18:31 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020116214207.00b4f980@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 21:43:13 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Summary of issues from DHCPv6 spec last call In-Reply-To: <4.3.2.7.2.20020116142534.0366bcf0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 626 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please ignore my previous message to this list - I'll post a complete summary of the discussion of the DHCPv6 draft tomorrow. - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGT020843 for ; Wed, 13 Feb 2002 19:40:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Pmrh020094 for ipng-dist; Wed, 13 Feb 2002 19:25:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGJ019898 for ; Wed, 13 Feb 2002 19:24:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12094 for ; Wed, 13 Feb 2002 19:18:42 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22151 for ; Wed, 13 Feb 2002 20:18:41 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Wed, 02 Jan 2002 21:19:59 -0800 Status: RO X-Status: X-Keywords: X-UID: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Now it is certainly true that communicating information is a waste of > time if the information can't be used -- but it is also true that there's > no point figuring out how to use the information if there's no way to > communicate it. the ietf is becoming full of mechanisms of little use. yet there remain some very hard but useful and known to be usable problems to solve. can we spend our energies on these? on the other hand, there is the theory that it is better that idle hands be occupied with useless but non-damaging work lest they find damaging things to do. the problem with this approach is that the router code bases are unreliable and unstable. any unneeded additions will only make them worse. randy, a big fan of mbz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHL020843 for ; Wed, 13 Feb 2002 19:41:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PgwX020088 for ipng-dist; Wed, 13 Feb 2002 19:25:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXG9019898 for ; Wed, 13 Feb 2002 19:24:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11906 for ; Wed, 13 Feb 2002 19:18:23 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02520 for ; Wed, 13 Feb 2002 19:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Mon, 14 Jan 2002 11:24:17 -0800 Nokia Silicon Valley Messaging Protection Message-Id: <4.3.2.7.2.20020114112109.0249e730@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 11:23:04 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 509 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : IPv6 Host to Router Load Sharing Author(s) : B. Hinden Filename : draft-ietf-ipv6-host-load-sharing-00.txt Pages : 4 Date : 10-Jan-02 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two weeks from today on January 28, 2002. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIL020843 for ; Wed, 13 Feb 2002 19:41:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VYYN020417 for ipng-dist; Wed, 13 Feb 2002 19:31:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GV020208 for ; Wed, 13 Feb 2002 19:30:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16769 for ; Wed, 13 Feb 2002 19:19:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07445 for ; Wed, 13 Feb 2002 20:19:04 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Thu, 24 Jan 2002 16:51:18 -0800 Nokia Silicon Valley Messaging Protection Message-Id: <4.3.2.7.2.20020124165004.024155b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 16:50:56 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 971 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the correction. My error in the announcement. Bob At 06:20 PM 1/23/2002, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 23 Jan 2002 10:40:49 -0800, > >>>>> Bob Hinden said: > > > This is a IPv6 working group last call for comments on advancing the > > following document as an Informational RFC: > >Thanks for the announcement. Here is a tiny (and perhaps trivial) >correction: > > > This document will replace RFC2592 that is an Informational RFC. The > > changes from RFC2592 are listed in section 17 of the internet draft. > >These "RFC2592" should be "RFC2292", of course. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIT020843 for ; Wed, 13 Feb 2002 19:41:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dZsn020813 for ipng-dist; Wed, 13 Feb 2002 19:39:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcG3020453 for ; Wed, 13 Feb 2002 19:38:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05105 for ; Wed, 13 Feb 2002 19:19:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02803 for ; Wed, 13 Feb 2002 19:19:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jan 2002 14:39:06 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkQw5CJxOTxJSNTZSmzWO6NIbXvAAGqe4A From: "Michel Py" To: "JJ Behrens" , "Tony Hain" Cc: "Keith Moore" , "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NMd22Q020793 Status: RO X-Status: X-Keywords: X-UID: 932 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > JJ Behrens wrote: > Please forgive me for being a newbie, but it seems wise to > allow subnetting of the lower 64 bits. Afterall, it would > be terrible if my dialup ISP assigned a /64 to me, and I > had to rely on some IPv6 mythical NAT to do subnetting! I don't think this will happen. IPv6 ISPs currently assign /48 prefixes (see www.freenet6.net for example) which gives you 65536 subnets to play. Besides, doing subnets on a dial-up connection looks rather overkill to me. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekI1020843 for ; Wed, 13 Feb 2002 19:41:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JSPx019775 for ipng-dist; Wed, 13 Feb 2002 19:19:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HrFh019508 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12185 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21746 for ; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C3377F8.6B9259AF@txc.com> Date: Wed, 02 Jan 2002 16:13:28 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C6D247BC51E28801A9EDD7E" Status: RO X-Status: X-Keywords: X-UID: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2C6D247BC51E28801A9EDD7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Let's take one simple example: **begin of example let's consider three neighboring routers: R1, R2, R3, forwarding one flow, characterized by src=a, dst=b, flow-label=10000, from R1 to R2, to R3. Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). Output interfaces are O1(R1), O2(R2), O3(R3). flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow If for R2's I2's classification engine, flow label value 10, is significantloy better than 10000, R2 could notify R1, to change the value 10000 to 10, when forwarding the flow on interface O1 towards I2. R2 would also remember that on forwarding the flow internally from I2 to O2, it has to restore the value to 10000. Consequetly, R2 would classify the flow on I2, with value 10 instead of 10000, and forward it further on O2 after changing the value 10 to value 10000. The flow would arrive to R3 through I3, with flow label value 10000. **end of example. How is the mutability used by R1, and R2, affect R3 which is not part of the signaling between R1, and R2? It does not! There are cases in which network (forwarding) devices are the best to know what are the most optimum values for the flow label field. An adequate flow setup mechanism can take care of any local flow label value modification, and in the same time, restore flow label values to eliminate the effects on the rest of the network. How would you ensure that such devices can maximize their potential, if you do not leave any window of flexibility? Regards, Alex Brian E Carpenter wrote: > > Alex, > > I don't agree. This restores the uncertainty that is preventing any > current usage. > > Brian > > Alex Conta wrote: > > > > Making the field "immutable" by "default", but "mutable" when a router > > is so instructed by a flow setup and flow processing mechanism is a > > compromise that would satisfy all current and future possible cases. > > > > Therefore I think last sentence of the first paragraph > > > > All routers MUST pass the field on unchanged when forwarding a > > packet. > > > > should be something like: > > > > All routers MUST leave the field unchanged, by default, when > > forwarding a packet. > > A specific flow setup/processing mechanism MAY give a "mutable" > > character to the field, > > by requesting routers, supporting the mechanism, to change the field > > in certain ways. > > Routers supporting such a mechanism MUST follow the steps indicated > > by the flow > > setup and flow processing mechanism. > > > > Alex > > > > Brian E Carpenter wrote: > > > > > > Taking Scott's suggestion, here's another try: > > > > > > I'd like to propose the following as the > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to uniquely label sets of packets. Nodes that do not support > > > the Flow Label field MUST set the field to zero when originating a > > > packet, and MUST ignore the field when receiving a packet. All routers > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > This specification does not further define the meaning of the > > > Flow Label. > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > Brian > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms2C6D247BC51E28801A9EDD7E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDIyMTEzMzBaMCMGCSqGSIb3DQEJ BDEWBBSdNDu6KMpfwAgb6TVdaAprzj6GqDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHEq+AOWZyZwk87CLjoh/vOsTnkTT8GuvT8PQntoT5B/1v+8 5JHmvAhbuXqrf64rU6f83BgukGMXezeJ+mnUr7tw42+/gwnIB9XauAn07e+Am/++8PrhnLDd lVpe3TIKZN/zdWTdrcAFSyQCEIK3cgKL5IiUfgxXTj3IFQAJjwhB --------------ms2C6D247BC51E28801A9EDD7E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHP020843 for ; Wed, 13 Feb 2002 19:41:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Pk7e020091 for ipng-dist; Wed, 13 Feb 2002 19:25:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFn019898 for ; Wed, 13 Feb 2002 19:24:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11692 for ; Wed, 13 Feb 2002 19:18:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02406 for ; Wed, 13 Feb 2002 19:17:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201031854.g03Isui15041@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "James Kempf" cc: "Brian E Carpenter" , ipng@sunroof.eng.sun.com, "Richard Carlson" Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] In-reply-to: Your message of "Thu, 03 Jan 2002 09:44:16 PST." <008101c1947e$4395b780$7e6015ac@T23KEMPF> Date: Thu, 03 Jan 2002 13:54:56 -0500 Status: RO X-Status: X-Keywords: X-UID: 84 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hum. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHv020843 for ; Wed, 13 Feb 2002 19:41:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VG0p020407 for ipng-dist; Wed, 13 Feb 2002 19:31:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5G7020208 for ; Wed, 13 Feb 2002 19:30:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16397 for ; Wed, 13 Feb 2002 19:18:32 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13691 for ; Wed, 13 Feb 2002 20:18:27 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 22:22:44 +0200. Date: Tue, 08 Jan 2002 11:28:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 258 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Also, this would get more difficult in the case of multiple, changing paths (multihoming). => as multi-homing is a place we could want to use home address options this is a real issue... Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGj020843 for ; Wed, 13 Feb 2002 19:41:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PxVg020104 for ipng-dist; Wed, 13 Feb 2002 19:25:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFv019898 for ; Wed, 13 Feb 2002 19:24:37 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11802 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28015 for ; Wed, 13 Feb 2002 19:18:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201021502.g02F2mi08013@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Scott Bradner cc: brian@hursley.ibm.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com, mat@cisco.com Subject: Re: Flow Label In-reply-to: Your message of "Wed, 02 Jan 2002 08:42:09 EST." <200201021342.g02Dg9Q08853@newdev.harvard.edu> Date: Wed, 02 Jan 2002 10:02:48 -0500 Status: RO X-Status: X-Keywords: X-UID: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? because the sending computer (application) knows the nature of the traffic? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekI9020843 for ; Wed, 13 Feb 2002 19:41:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dvTN020824 for ipng-dist; Wed, 13 Feb 2002 19:39:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcG5020453 for ; Wed, 13 Feb 2002 19:38:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05059 for ; Wed, 13 Feb 2002 19:18:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13936 for ; Wed, 13 Feb 2002 20:18:58 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 24 Jan 2002 11:20:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Status: RO X-Status: X-Keywords: X-UID: 937 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 23 Jan 2002 10:40:49 -0800, >>>>> Bob Hinden said: > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: Thanks for the announcement. Here is a tiny (and perhaps trivial) correction: > This document will replace RFC2592 that is an Informational RFC. The > changes from RFC2592 are listed in section 17 of the internet draft. These "RFC2592" should be "RFC2292", of course. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHt020843 for ; Wed, 13 Feb 2002 19:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Vdc9020420 for ipng-dist; Wed, 13 Feb 2002 19:31:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GT020208 for ; Wed, 13 Feb 2002 19:30:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16402 for ; Wed, 13 Feb 2002 19:18:35 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28208 for ; Wed, 13 Feb 2002 19:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" Cc: , References: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Sun, 6 Jan 2002 18:43:51 +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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: X-Keywords: X-UID: 187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => this (to use AAA everywhere where there are mobile nodes) is the price > to pay to have an alternative to bidirectional tunnels with home agents, > i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling > (i.e. real world mobile IPv4). This seems like a bad design tradeoff to me. We already have a highly optimised mode of operation in MIPv6 (RO), and if you're not using it you are falling back to something less efficient. Your tradeoff improves the fallback solution a bit, but doesn't improve the optimised solution. And the cost is extreme: we need a new global infrastructure (though I admit some of it will be built anyway), MIPv6 deployment is delayed, most if not all small sites and homes will not be able to benefit from RO, etc. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHr020843 for ; Wed, 13 Feb 2002 19:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jm88019791 for ipng-dist; Wed, 13 Feb 2002 19:19:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I6Fh019624 for ; Wed, 13 Feb 2002 19:18:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11606 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06910 for ; Wed, 13 Feb 2002 20:17:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C32FD37.B79CDE36@hursley.ibm.com> Date: Wed, 02 Jan 2002 13:29:43 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Alex Conta Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I don't agree. This restores the uncertainty that is preventing any current usage. Brian Alex Conta wrote: > > Making the field "immutable" by "default", but "mutable" when a router > is so instructed by a flow setup and flow processing mechanism is a > compromise that would satisfy all current and future possible cases. > > Therefore I think last sentence of the first paragraph > > All routers MUST pass the field on unchanged when forwarding a > packet. > > should be something like: > > All routers MUST leave the field unchanged, by default, when > forwarding a packet. > A specific flow setup/processing mechanism MAY give a "mutable" > character to the field, > by requesting routers, supporting the mechanism, to change the field > in certain ways. > Routers supporting such a mechanism MUST follow the steps indicated > by the flow > setup and flow processing mechanism. > > Alex > > Brian E Carpenter wrote: > > > > Taking Scott's suggestion, here's another try: > > > > I'd like to propose the following as the > > complete and total replacement of Section 6 of RFC 2460. > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > [and delete Appendix A, which is unhelpful.] > > > > Brian > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHT020843 for ; Wed, 13 Feb 2002 19:41:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3ViaY020426 for ipng-dist; Wed, 13 Feb 2002 19:31:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GZ020208 for ; Wed, 13 Feb 2002 19:30:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16279 for ; Wed, 13 Feb 2002 19:18:14 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14739 for ; Wed, 13 Feb 2002 20:18:14 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201031807.g03I7Ii14740@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Steven M. Bellovin" cc: Randy Bush , Keith Moore , Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "Thu, 03 Jan 2002 12:34:07 EST." <20020103173407.D319C7B55@berkshire.research.att.com> Date: Thu, 03 Jan 2002 13:07:18 -0500 Status: RO X-Status: X-Keywords: X-UID: 80 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >and, if we do mbz, they can then write the rfc which changes that > > The problem then is all the implementations -- or firewalls -- that > will check that the bits really are zero upon receipt. If you want > MBZ, say "sender MUST set to zero; receiver and middle boxes MUST NOT > check". right. > Then you have to hope that folks listen to that part. Especially for > firewalls, I wouldn't count on that. nor I. but clearly stating that routers and firewalls are supposed to ignore Flow Label is probably the best we can do. Keith p.s. I *wish* we had a mechanism for clearly pointing the finger at intermediaries that cause application failures by violating the specs - it would be so wonderful if an application could say "you aren't receiving any incoming mail because your boneheaded network administrator installed a firewall that won't permit SMTP over TLS traffic to pass" complete with a clickable button that says "Terminate Administrator" (and another that says "...With Extreme Prejudice") -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGb020843 for ; Wed, 13 Feb 2002 19:40:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Ptxs020102 for ipng-dist; Wed, 13 Feb 2002 19:25:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXG3019898 for ; Wed, 13 Feb 2002 19:24:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11817 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14701 for ; Wed, 13 Feb 2002 20:18:07 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201082006.g08K6f525669@spidey.speakeasy.net> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Tue, 8 Jan 2002 12:06:40 -0800 From: Qing Li To: ipng@sunroof.eng.sun.com Subject: Question on draft-ietf-ipngwg-rfc2096-update-00 X-Sender: qingli@speakeasy.net X-Originating-Ip: [147.11.38.42] X-Mailer: Speakeasy Network Webmail 2.1.0 Status: RO X-Status: X-Keywords: X-UID: 281 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The inetCidrRouteTable refers to the node's routing table, not the forwarding table inside the kernel (such as FreeBSD), is that correct? If the router participates in multiple routing domains then this table should contain routing info from multiple routing tables, is that so? Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIH020843 for ; Wed, 13 Feb 2002 19:41:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dApM020793 for ipng-dist; Wed, 13 Feb 2002 19:39:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFp020453 for ; Wed, 13 Feb 2002 19:38:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05062 for ; Wed, 13 Feb 2002 19:18:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02760 for ; Wed, 13 Feb 2002 19:18:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Jan 2002 08:13:44 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE67@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkJ8419cqcn8j2RcqRRJXTewtQxwAALK6w From: "Michel Py" To: "Keith Moore" , "Irina Dayal" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NGDd2Q020102 Status: RO X-Status: X-Keywords: X-UID: 901 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Irina Dayal wrote: > 1) Is it safe to assume that all IPv6 prefixes will be between >> 16 and 64 bits long? > Keith Moore wrote: > no. because nothing requires a site to use the lower 64 bits > as an interface ID - a site is free to subnet that space if > it wishes. I have to disagree with Keith here. If a site wants to subnet, they get a /48 and use the 16 SLA bits to subnet, that is what they have been designed for. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHV020843 for ; Wed, 13 Feb 2002 19:41:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dHoL020804 for ipng-dist; Wed, 13 Feb 2002 19:39:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFt020453 for ; Wed, 13 Feb 2002 19:38:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05106 for ; Wed, 13 Feb 2002 19:19:08 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13957 for ; Wed, 13 Feb 2002 20:19:02 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Thu, 24 Jan 2002 16:46:59 -0800 Nokia Silicon Valley Messaging Protection Message-Id: <4.3.2.7.2.20020124164024.02e17e00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 16:45:51 -0800 To: "Jim Fleming" From: Bob Hinden Subject: Jim Fleming's off topic postings to ipng mailing list Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 970 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mr. Fleming, The ipng mailing list is for the use of the IETF's IPv6 working group. The chairs of the IPv6 working group believe that many of your recent postings to the ipng mailing list have been off topic and are disruptive to the work of the working group. Your posts have included topics that are not within scope of the working group and others that provide incorrect information about IPv6. If you can not keep your postings within the scope of the working group mailing list, we will instruct the list administrator to block your posts to the mailing list. Regards, Bob Hinden & Steve Deering IPv6 working group chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHj020843 for ; Wed, 13 Feb 2002 19:41:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jj9t019786 for ipng-dist; Wed, 13 Feb 2002 19:19:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I0Fh019574 for ; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04638 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27930 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C35793C.CB24C2B6@hursley.ibm.com> Date: Fri, 04 Jan 2002 10:43:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: FlowLabel] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <4.2.2.20020103112950.045b4320@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 117 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > >So, I think it's time for a hum on this one (the simple > >update to 2460 that Scott and I at least seem to agree > >on). > > Hum. > > Could someone publish an internet draft with this wording? > The only draft that we have now is pretty far away from this. Good point. What we need is a short simple draft to update 2460, independent of draft-rajahalme- . Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGn020843 for ; Wed, 13 Feb 2002 19:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dvRm020823 for ipng-dist; Wed, 13 Feb 2002 19:39:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGH020453 for ; Wed, 13 Feb 2002 19:38:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04820 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13779 for ; Wed, 13 Feb 2002 20:18:35 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Gerard.Gastaud@alcatel.fr Cc: Brian E Carpenter , Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 12:26:08 -0500 Message-Id: <20020110172608.2D4A37B69@berkshire.research.att.com> Status: RO X-Status: X-Keywords: X-UID: 367 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Gerard.Gastaud@alc atel.fr writes: > > > >and the user may refuse to pay because it idid not ask for the flow label that the malicious entity overwrote An enemy who is overwriting flow labels could generate fake packets with arbitrary flow labels. It's strictly easier -- instead of deleting and reinserting packets, you just generate them, with any fields you want. If the routers can't cryptographically verify every flow labeled-packet -- and they can't do that in any rational fashion, I suspect -- then the only other choice is border control. Your border routers -- including the peering routers, if necessary -- have to check that incoming packets are, in some sense, "legal". In particular, if you're going to charge someone extra for such services, you have to ensure that the right party sent the packets. (This creates an interesting problem at peering links -- what do you do with packets that have a legal flow label for the peer, but not for you?) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3guFh021091 for ; Wed, 13 Feb 2002 19:42:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gukk021090 for ipng-dist; Wed, 13 Feb 2002 19:42:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5H3020208 for ; Wed, 13 Feb 2002 19:31:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16467 for ; Wed, 13 Feb 2002 19:18:34 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02551 for ; Wed, 13 Feb 2002 19:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Gerard.Gastaud@alcatel.fr X-Lotus-FromDomain: ALCATEL To: Brian E Carpenter cc: Subrata Goswami , ipng@sunroof.eng.sun.com Message-ID: Date: Thu, 10 Jan 2002 16:29:04 +0100 Subject: Re: Flow Label Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n" Content-Disposition: inline Status: RO X-Status: X-Keywords: X-UID: 364 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable and the user may refuse to pay because it idid not ask for the flow lab= el that the malicious entity overwrote g=E9rard Brian E Carpenter on 10/01/2002 15:09:10 =20 =20 =20 To: Subrata Goswami =20 =20 cc: ipng@sunroof.eng.sun.com(bcc: Gerard =20 GASTAUD/FR/ALCATEL) =20 =20 =20 =20 Subject Re: Flow Label =20 : =20 =20 = --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? You can't, any more than you can be sure the DSCP hasn't changed, or that somebody isn't playing games with port numbers to fool your classifier. The ISP's defence against this is that more QoS will result in a higher bill. So the ISP actually doesn't care; they get paid accordingly. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --0__=P5yXQqbY1cKWjzN7eAEixbkTSK0UIS2lAhh8WEL9Rs8srN655nLP5w8n-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:44:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3iaFh021183 for ; Wed, 13 Feb 2002 19:44:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3iaoK021182 for ipng-dist; Wed, 13 Feb 2002 19:44:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0H9020775 for ; Wed, 13 Feb 2002 19:39:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12415 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02438 for ; Wed, 13 Feb 2002 19:18:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <933FADF5E673D411B8A30002A5608A0E014CBED9@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Brian E Carpenter Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 2 Jan 2002 13:57:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C193C7.BD4E12F0" Status: RO X-Status: X-Keywords: X-UID: 158 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C193C7.BD4E12F0 Content-Type: text/plain; charset="iso-8859-1" Brian, Diff-serv itself is a sort of signaling and the field it operates on is mutable is it not? I hope you at least agree that is is either configured or signaled. I believe you can signal to routers and have routers that are not configured or capable of handling the signaling ignore the signaling. IPv6's option definitions were designed specifically for this filtering function. So I guess what I'm saying is, the example you gave to indicate that the fields should be immutable is not immutable itself and so I don't think the reasoning holds up. Making the field mutable or not is disjoint from the signaling or configuration argument in order to act on a field. With diff-serv you either configure or signal to set up the behavior of its operational field. The merits of configuration vs signaling might be argued but IMO configuration (especially remote configuration) is a form of signaling as well. I do see value in out of the box schemas for on-net solutions; however, I don't think mutability will thwart this ability or desire as long as the signaling or subsequent configuration can change the default schema. I also don't understand why people are so terrified of mutability of certain fields. The original point was that if there is a business reason to make a field mutable or not, it will be mutable irrespective of what an RFC says. It seems to me that making things immutable reduces the use of the fields in question from a functional perspective. Mutability with signaling and at least configuration seems to increase flexibility and extensibility. It seems to me that for the long term we should not try to restrict the use of fields but rather detail the use and expectations for particular applications as their need arises. I don't see a problem with an RFC saying, "for this particular network layer service, the field is expected to be immutable as it traverses certain parts of the network or the whole network". But this would be for just one type of network-layer service and would leave the door open for other uses in the future. regards, Glenn > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, December 23, 2001 9:17 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > Glenn Morrow wrote: > > > If "function A" wants the field immutable so be it. The > signaling for "function A" needs to convey the mutability > rules to affected parties > > either implicitly or by optionality. > > This is broken. You can't signal to routers that aren't aware of > the "function A", because they won't be aware of the relevant > signalling either. Also, we need to be able to construct > signalling-free > solutions (such as diffserv) for scalability. > > Immutability is the only viable answer. > > Brian > > > ------_=_NextPart_001_01C193C7.BD4E12F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-rajahalme-ipv6-flow-label-00.txt

Brian,

Diff-serv itself is a sort of signaling and the field = it operates on is mutable is it not? I hope you at least agree that is = is either configured or signaled. I believe you can signal to routers = and have routers that are not configured or capable of handling the = signaling ignore the signaling. IPv6's option definitions were designed = specifically for this filtering function.

So I guess what I'm saying is, the example you gave = to indicate that the fields should be immutable is not immutable itself = and so I don't think the reasoning holds up. Making the field mutable = or not is disjoint from the signaling or configuration argument in = order to act on a field. With diff-serv you either configure or signal = to set up the behavior of its operational field. The merits of = configuration vs signaling might be argued but IMO configuration = (especially remote configuration) is a form of signaling as well. I do = see value in out of the box schemas for on-net solutions; however, I = don't think mutability will thwart this ability or desire as long as = the signaling or subsequent configuration can change the default = schema.

I also don't understand why people are so terrified = of mutability of certain fields. The original point was that if there = is a business reason to make a field mutable or not, it will be mutable = irrespective of what an RFC says. It seems to me that making things = immutable reduces the use of the fields in question from a functional = perspective. Mutability with signaling and at least configuration seems = to increase flexibility and extensibility. It seems to me that for the = long term we should not try to restrict the use of fields but rather = detail the use and expectations for particular applications as their = need arises. I don't see a problem with an RFC saying, "for this = particular network layer service, the field is expected to be immutable = as it traverses certain parts of the network or the whole = network". But this would be for just one type of network-layer = service and would leave the door open for other uses in the = future.

regards,

Glenn

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Sunday, December 23, 2001 9:17 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Margaret Wasserman; = ipng@sunroof.eng.sun.com
> Subject: Re: = draft-rajahalme-ipv6-flow-label-00.txt
>
>
> Glenn Morrow wrote:
>
> > If "function A" wants the field = immutable so be it. The
> signaling for "function A" needs to = convey the mutability
> rules to affected parties
> > either implicitly or by optionality. =
>
> This is broken. You can't signal to routers = that aren't aware of
> the "function A", because they won't = be aware of the relevant
> signalling either. Also, we need to be able to = construct
> signalling-free
> solutions (such as diffserv) for = scalability.
>
> Immutability is the only viable answer.
>
>   Brian
>
>
>

------_=_NextPart_001_01C193C7.BD4E12F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gNFh021051 for ; Wed, 13 Feb 2002 19:42:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gNGP021050 for ipng-dist; Wed, 13 Feb 2002 19:42:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fj020775 for ; Wed, 13 Feb 2002 19:39:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12418 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28073 for ; Wed, 13 Feb 2002 19:18:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020109133137.00b8f698@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:35:25 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: DHCPv6 spec in DHC WG last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 326 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The latest rev of the DHCPv6 spec is now available at www.ietf.org. This spec is now in DHC WG last call review. We'd also like to get feedback from interested member of the IPv6 WG as well. Please respond with comments on draft-ietf-dhc-dhcpv6-22.txt to the DHC WG mailing list, dhcwg@ietf.org. - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIN020843 for ; Wed, 13 Feb 2002 19:41:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jli4019789 for ipng-dist; Wed, 13 Feb 2002 19:19:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I1Fh019587; Wed, 13 Feb 2002 19:18:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04632; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14585; Wed, 13 Feb 2002 20:17:54 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Wed, 26 Dec 2001 21:38:53 +0200. <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> Date: Fri, 04 Jan 2002 16:37:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-Status: X-Keywords: X-UID: 125 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? => this is a problem of trust in the local/visited domain *and* in the remote/home domain. In your example if I understand the issue is the lack of trust in the local/visited domain, so one may reject traffic with home address options from it. Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. => my concern is that the "mandatory" term in a RFC is not enough to enforce it in the real world. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. => ingress filtering has more problems with IPv4, mainly because it was not considered from the beginning. But it is already a BCP and it seems that most ISPs use it (feedback from ISPs please). Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... => we can expect to avoid the same errors with IPv6. Unfortunately ingress filtering (like network management) is something where IPv6 is not yet at the same level than for IPv4 today. We hope this situation will be improved very fast. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:43:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3hTFh021125 for ; Wed, 13 Feb 2002 19:43:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3hTVF021124 for ipng-dist; Wed, 13 Feb 2002 19:43:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gx020775 for ; Wed, 13 Feb 2002 19:39:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12377 for ; Wed, 13 Feb 2002 19:18:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28007 for ; Wed, 13 Feb 2002 19:18:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C397521.A5D1660F@hursley.ibm.com> Date: Mon, 07 Jan 2002 11:14:57 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 208 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We've already discussed the weak trust model aspect. Basically nobody will be doing cryptographic authentication of the flow label at line speed, and if it isn't done at line speed what's the point? Brian Subrata Goswami wrote: > > The wording for immutability aside, to really enforce immutability > of the Flow Label , there must be a mechanism to verify that the > Flow Label has not been changed. As can be seen from the ICV computation > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence there > needs to be a new IPv6 header option for Flow Label immutability. > > 3.3.3.1.2 ICV Computation for IPv6 > > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) > Source Address > Destination Address (without Routing Extension Header) > > Mutable but predictable > Destination Address (with Routing Extension Header) > > Mutable (zeroed prior to ICV calculation) > Class > Flow Label > Hop Limit > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins > Sent: Friday, January 04, 2002 9:33 AM > To: Brian E Carpenter > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > Hello Brian, > > Brian E Carpenter wrote: > > > > And, truth in advertising, we have heard two dissenting > > views: > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > the MAY clause below gets deleted > > I would say that MAY is a lot better. It suggests the truth, > which is that people are going to try to figure out ways to > use the flow label. It also motivates immutability. Otherwise, > it is possible that some router vendors could simply zero out > the field -- if it MUST BE ZERO, then zeroing it preserves > immutability... We wouldn't want that. > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > be default instead of mandatory. > > Any future technique for using the flow label would, if it violates > immutability, be viewed as obsoleting this part of the specification > anyway. So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user > interface labeled thusly: > "Flow Label treatment (default: do not change): " > to be filled in by the system administrator. Possible other values > selectable by the operator could be "randomize", "ones-complement", > "store current time", ... (?). I don't know why anyone would do > this, but I think we ought to be pretty clear about prohibiting it > at least for now. > > Regards, > Charlie P. > > > > > Brian > > > > Margaret Wasserman wrote: > > > > > > Hi George, > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > replace section 6 of RFC 2460 with the following text: > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All > routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > just publish a separate RFC that updates 2460. > > > > > > Margaret > > > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > > >Just a quick question from an interested lurker: Are these hums of > > > >acquiescence in response, specifically, to the idea that an originating > > > >node may set the flow label to any value, and that nodes forwarding > > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIB020843 for ; Wed, 13 Feb 2002 19:41:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VOcI020411 for ipng-dist; Wed, 13 Feb 2002 19:31:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GH020208 for ; Wed, 13 Feb 2002 19:30:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16159 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13483 for ; Wed, 13 Feb 2002 20:18:04 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Fri, 4 Jan 2002 09:40:46 -0800 Nokia Silicon Valley Messaging Protection Message-ID: <3C35E91D.37D93CC1@iprg.nokia.com> Date: Fri, 04 Jan 2002 09:40:45 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Oops! Typo! Re: Flow Label References: <4.2.2.20020103144313.045caa60@mail.windriver.com> <3C3586EE.9B8D002A@hursley.ibm.com> <3C35E74F.40A490D7@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 142 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Typo alert in my last message: "Charles E. Perkins" wrote: > ... So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user knob > interface labeled thusly: ... Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekI7020843 for ; Wed, 13 Feb 2002 19:41:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dcBV020815 for ipng-dist; Wed, 13 Feb 2002 19:39:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFx020453 for ; Wed, 13 Feb 2002 19:38:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05054 for ; Wed, 13 Feb 2002 19:18:58 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15071 for ; Wed, 13 Feb 2002 20:18:57 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f content-class: urn:content-classes:message Subject: RE: IPv6 Addr/Prefix clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Jan 2002 08:09:57 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C262@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Addr/Prefix clarification Thread-Index: AcGkG6ecv5dByaObRAm9PkWZ/L7jMAADBv4g From: "Michel Py" To: "Irina Dayal" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0NG9t2Q020076 Status: RO X-Status: X-Keywords: X-UID: 895 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Irina Dayal wrote: > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 > bits long? The current allocation of IPv6 prefixes seems to require > Aggregatable Global Unicast Addresses, which restricts the prefixes to > this range. It's not safe (even if it might be true today). Slightly more than 1/8 of the IPv6 address space has been allocated to a purpose so far. There are drafts that are mentionning allocating 0001, which is a /4. Even today, one might want to configure 2000::/3 as the default route instead of 0::/0. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3fNFh020940 for ; Wed, 13 Feb 2002 19:41:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3fNLO020936 for ipng-dist; Wed, 13 Feb 2002 19:41:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcH1020453 for ; Wed, 13 Feb 2002 19:39:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05073 for ; Wed, 13 Feb 2002 19:19:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02762 for ; Wed, 13 Feb 2002 19:18:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 24 Jan 2002 09:07:55 -0500 (EST) From: Jim Bound To: ipng@sunroof.eng.sun.com Subject: Last Issue for Base API Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 950 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, This is the last issue for the base api . We will send in final draft for INfo RFC annouce from the chairs. The only change will be to add Jack McCann as co-author to the base API current draft spec. This request is out of scope for this API. It could be an extension to the Advanced API possibly. I will send in new ID and to Steve and Bob to send ton IESG for INFO RFC Last Call. Thanks to the entire working group and the hard work and collaboration of the IEEE . This has been a longgggggggggggggg process. /jim > > >Date: Mon, 17 Dec 2001 09:08:32 -1000 (HST) > > >From: Antonio Querubin > > >To: Bob Hinden > > >cc: > > >Subject: Re: IPv6 w.g. Last Call on "Basic Socket Interface > > Extensions for > > > IPv6" > > >Sender: owner-ipng@sunroof.eng.sun.com > > > > > >On Tue, 11 Dec 2001, Bob Hinden wrote: > > > > > > > This is a IPv6 working group last call for comments on > > advancing the > > > > following document as an Informational RFC: > > > > > > > > Title : Basic Socket Interface Extensions for IPv6 > > > > Author(s) : R. Gilligan, S. Thomson, J. > > Bound, W. Stevens > > > > Filename : draft-ietf-ipngwg-rfc2553bis-04.txt > > > > Pages : 32 > > > > Date : 27-Nov-01 > > > > > > > > This document will replace RFC2553 that is currently an > > Informational > > > > RFC. The changes from RFC2553 are listed on pages 29 and > > 30 of the draft. > > > > > > > > Please send substantive comments to the ipng mailing > > list, and minor > > > > editorial comments to the authors. This last call period > > will end two > > > > weeks from today on December 26, 2001. > > > > > > > > Bob Hinden / Steve Deering > > > > > >This may be a bit late but I do think that the API should > > address better > > >compatibility with IPv4 multicast. There was some > > discussion earlier this > > >year about this but no consensus was reached other than that > > it should be > > >fixed. > > > > > >The problem I think would be helped if, for the purposes of this API, > > >section 3.7 was extended to optionally allow for a pseudo IPv4-mapped > > >multicast address. I'm suggesting adding two sentences to > > paragraph 2 of > > >section 3.7: > > > > > >"These addresses can be generated automatically by the getaddrinfo() > > >function, when the specified host has only IPv4 addresses > > (as described in > > >Section 6.1 and 6.2). For the purposes of this API, the > > allowed range of > > > may be extended beyond that defined in RFC > > 2373 to also > > >include multicast addresses. The resulting mapped address should be > > >treated as a multicast address." > > > > > >This addition is motivated by one of the design > > considerations of the API: > > > > > >" - Where possible, applications should be able to use this > > > API to interoperate with both IPv6 and IPv4 hosts. > > Applications > > > should not need to know which type of host they are > > > communicating with." > > > > > >And further down we have: > > > > > >"Because of the importance of providing IPv4 compatibility > > in the API, > > >these extensions are explicitly designed to operate on machines that > > >provide complete support for both IPv4 and IPv6." > > > > > > > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHb020843 for ; Wed, 13 Feb 2002 19:41:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Pw5T020103 for ipng-dist; Wed, 13 Feb 2002 19:25:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGV019898 for ; Wed, 13 Feb 2002 19:24:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11681 for ; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02399 for ; Wed, 13 Feb 2002 19:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C348472.DD2BE3C9@hursley.ibm.com> Date: Thu, 03 Jan 2002 17:18:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Randy Bush Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 64 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, The proposed new words for 2460 effectively say - you don't have to set it - you don't have to look at it - you mustn't change it I don't think encourages kludge significantly more than MBZ text, but it does allow for future usage. Brian Randy Bush wrote: > > >> I do not believe that there is currently any way to deal with the > >> *business* and *operational* issues of asking some remote ISP > >> to provide QoS service for you in any sort of scalable way > > Fine, but that's completely orthogonal to whether the flow label is > > a good idea or not. > > we don't care that no one can operationally use it. if it might sell > one more router, let's kludge up the net a bit more. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ghFh021075 for ; Wed, 13 Feb 2002 19:42:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3ghko021074 for ipng-dist; Wed, 13 Feb 2002 19:42:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGl020453 for ; Wed, 13 Feb 2002 19:39:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04786 for ; Wed, 13 Feb 2002 19:18:35 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13742 for ; Wed, 13 Feb 2002 20:18:34 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020116142534.0366bcf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 21:32:02 -0500 To: Bernie.Volz@am1.ericsson.se From: Ralph Droms Subject: Summary of issues from DHCPv6 spec last call Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 625 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernie - I've been in allday meetings Mon and Tue, and more meetings for a good part of today. I put together the following message to send to the dhcwg and ipng mailing lists, summarizing the comments during the last call. There is one more batch of comments from Vijay Bhaskar A K that I need to address. Would you please review this message and confirm that I've captured all of the threads from the last call? Thanks... I will be travelling Thu and Fri, but will be checking e-mail intermittently... - Ralph The following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today: Open issues ----------- * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - Fix redundancy between sections 18.2.5 and 18.2.8 - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3g2Fh021026 for ; Wed, 13 Feb 2002 19:42:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3g2rR021024 for ipng-dist; Wed, 13 Feb 2002 19:42:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HB020208 for ; Wed, 13 Feb 2002 19:31:11 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16461 for ; Wed, 13 Feb 2002 19:18:32 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28223 for ; Wed, 13 Feb 2002 19:18:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201161201.HAA04499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-04.txt Date: Wed, 16 Jan 2002 07:01:44 -0500 Status: RO X-Status: X-Keywords: X-UID: 600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-04.txt Pages : 79 Date : 15-Jan-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2292bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020115095215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095215.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGP020843 for ; Wed, 13 Feb 2002 19:40:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JkWb019788 for ipng-dist; Wed, 13 Feb 2002 19:19:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I6Fh019617 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11609 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAB27919 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021342.g02Dg9Q08853@newdev.harvard.edu> <200201021502.g02F2mi08013@astro.cs.utk.edu> Message-Id: Date: Wed, 02 Jan 2002 07:11:26 -0800 Status: RO X-Status: X-Keywords: X-UID: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> why do folk think that ISPs half way around the world would find it >> useful to know what the sending computer wanted for QoS? > because the sending computer (application) knows the nature of the > traffic? no need to signal. we already know that they think their traffic is more important than everybody else's. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekFx020843 for ; Wed, 13 Feb 2002 19:40:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JedW019781 for ipng-dist; Wed, 13 Feb 2002 19:19:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HtFh019527 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11591 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27910 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 3 Jan 2002 11:01:41 -0800 (PST) Message-Id: <200201031901.g03J1fJu057738@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Flow Label Status: RO X-Status: X-Keywords: X-UID: 86 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a quick question from an interested lurker: Are these hums of acquiescence in response, specifically, to the idea that an originating node may set the flow label to any value, and that nodes forwarding packets will leave that value alone? -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:45:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3j7Fh021191 for ; Wed, 13 Feb 2002 19:45:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3j7cR021190 for ipng-dist; Wed, 13 Feb 2002 19:45:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Hp020208 for ; Wed, 13 Feb 2002 19:31:32 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16766; Wed, 13 Feb 2002 19:19:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28439; Wed, 13 Feb 2002 19:19:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201300418.g0U4IXR13192@minotaur.nge.isi.edu> To: Erik Nordmark cc: "Speciner, Michael" , ipng@sunroof.eng.sun.com Reply-To: mankin@isi.edu Subject: Re: IPv6 and mandatory UDP checksum In-reply-to: Your message of Tue, 29 Jan 2002 22:37:14 +0100. Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Jan 2002 23:18:33 -0500 From: Allison Mankin Status: RO X-Status: X-Keywords: X-UID: 972 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-tsvwg-udplite-00.txt The working group agreed to a working group last call, about to start. Allison > > > > So what should I do if I want to use IPv6, which mandates UDP checksums > > and requires receivers to discard UDP packets without checksums (i.e. > > with zero checksum)? I assume that there is also a mandate to discard > > UDP packets whose checksum is wrong, although I don't see that > > explicitly in either the UDP or IPv6 RFCs. > > I've been told there is supposed to be work on something called UDP-lite > in TSVWG - the ability to have the UDP checksum cover some number of bytes > in the packet (like e.g. just the pseudo-header, UDP header, and RTP header). > But I don't know how this work is progressing. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIF020843 for ; Wed, 13 Feb 2002 19:41:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dCXI020795 for ipng-dist; Wed, 13 Feb 2002 19:39:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFn020453 for ; Wed, 13 Feb 2002 19:38:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04685 for ; Wed, 13 Feb 2002 19:18:18 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28126 for ; Wed, 13 Feb 2002 19:18:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.20649.14164.404636@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 10:25:45 -0800 (PST) To: Scott Bradner Cc: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, moore@cs.utk.edu, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021814.g02IEad09837@newdev.harvard.edu> References: <200201021814.g02IEad09837@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Status: RO X-Status: X-Keywords: X-UID: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > Are you claiming that RFC 3182 (nee 2752) is > inadequate for interdomain? > > for telling someone who you are its fine but that does not even > start to address teh operational issues of how an ISP would make use > of the information There is already an existence proof: cellular. Nobody's claiming that this is easy though. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gUFh021059 for ; Wed, 13 Feb 2002 19:42:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gTpa021058 for ipng-dist; Wed, 13 Feb 2002 19:42:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gr020775 for ; Wed, 13 Feb 2002 19:39:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12463 for ; Wed, 13 Feb 2002 19:18:13 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02437 for ; Wed, 13 Feb 2002 19:18:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: "Dr. Subrata Goswami" cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2002 13:45:04 +0700 Message-ID: <874.1010558704@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 292 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 8 Jan 2002 21:28:11 -0800 From: "Dr. Subrata Goswami" Message-ID: | Here we go again, I guess first we need to make sure | what immutability really is. The proper semantic of | something immutable is that it can not be changed - | as when you ship a CD that is only readable. Yes, though we perhaps aren't using it in quite that sense, more in the "must not be changed" rather than "can not be changed". | With an IPv6 | packet that is not possible unless every router vendor | and IP stack vendor is some how forced to do that. But that's certainly not true. We don't have to force them, we just need to tell them what is right. That's all the IETF ever really does. | Even the IP address fields are mutable as any intervening router | can change (and they do in case of NAT). Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields have just the properties that we are really aiming for here. That is, they aren't changed by random routers along the path - packets get delivered with the same addresses in them that they had when they left the source (or did, pre NAT). And that was achieved without AH existing yet to validate things - the routers simply didn't alter the fields. That's what is desirable here. But then, along came the need for NAT (as evil as it is, there must be a pretty strong case for it, given its widespread use). Implementing that meant that the address field, which previously had never been altered, now needed to be changed by routers. Had there been any enforcement of the immutability of the addresses, then there would have been no way to add NAT to the net (which might have been good, or bad, but for sure the net now would be nothing like it is if not for it). | So the only way | to enforce immutability is to add something like the AH so | that anyone who is concerned with the Flow Label can be | sure that no router in the middle has tempered it. If there was any reason to enforce it, that would be correct. But there isn't - so we don't need this. And if we did, then there'd be no possibility later to come up with some new use which requires the field to be mutable (and argue about it a lot in the IETF and perhaps eventually agree to it). At this stage in the evolution of the flow label, completely cutting off that possibility is unreasonable. In practice, if actual immutability is required by applications that use the flow label, then what will "enforce" the immutability is the screams of the users at the router vendors/operators if they start playing about with the data. Just as would happen if (aside from the explicitly configured NAT, and even that generates plenty of screaming) routers started randomly changing IP addresses. If there's never an application actually deployed that cares, then why would anyone else? In that case, if someone decides to alter the field, no-one would notice - and there's no reason to go and add a mechanism just to detect something that no-one cares about anyway. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHN020843 for ; Wed, 13 Feb 2002 19:41:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VgYT020424 for ipng-dist; Wed, 13 Feb 2002 19:31:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Gf020208 for ; Wed, 13 Feb 2002 19:30:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16411 for ; Wed, 13 Feb 2002 19:18:35 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07169 for ; Wed, 13 Feb 2002 20:18:27 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201151401.g0FE1fQ51732@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Mon, 14 Jan 2002 11:23:04 PST. <4.3.2.7.2.20020114112109.0249e730@mailhost.iprg.nokia.com> Date: Tue, 15 Jan 2002 15:01:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 550 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There was a long and not very clear discussion about the level of requirement for this proposal... The current spec (RFC 2461 6.3.6 end of 1)) says: An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available. i.e. there are two proposed solutions with a small may (I interpret this as an implementation hint). The new proposal is: An implementation SHOULD pick routers from the default router list in random order while making sure it always returns a reachable or a probably reachable router when one is available. I have two concerns about this: - the random order is not defined (this is a formal concern because the intention is clear) - we moved from an implementation hint to a SHOULD, this will make old implementations not conformant and in some situations there can be far better solutions. So I prefer to get a MAY (enough to get this proposal implemented in the future by everybody without harm) and an explicit reference to the default router preference draft (first because I am in favor of this from the beginning, i.e. since many years, second because this is the best reply to the "special case" argument (not so special case because 100% of the IPv6 networks I used have several routers with a better one)). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekH7020843 for ; Wed, 13 Feb 2002 19:41:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PhdJ020089 for ipng-dist; Wed, 13 Feb 2002 19:25:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXG5019898 for ; Wed, 13 Feb 2002 19:24:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12277 for ; Wed, 13 Feb 2002 19:19:02 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22345 for ; Wed, 13 Feb 2002 20:19:01 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201241707.g0OH7ag09770@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Last Issue for Base API In-reply-to: Your message of Thu, 24 Jan 2002 09:07:55 EST. Date: Thu, 24 Jan 2002 18:07:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 961 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This is the last issue for the base api .... => so This shan't be considered as unfair to ask that the base API document is published "not after" the advanced API document? (there is a current WG last call on the advanced API, basic API seems to be ready for an IETF last call) Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekH5020843 for ; Wed, 13 Feb 2002 19:41:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JnTx019793 for ipng-dist; Wed, 13 Feb 2002 19:19:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IGFh019681 for ; Wed, 13 Feb 2002 19:18:18 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12295 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27948 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200201021922.g02JMSa10173@newdev.harvard.edu> <15411.27563.734410.55839@thomasm-u1.cisco.com> <15411.28923.226644.825039@thomasm-u1.cisco.com> Message-Id: Date: Wed, 02 Jan 2002 12:49:04 -0800 Status: RO X-Status: X-Keywords: X-UID: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>> I do not believe that there is currently any way to deal with the >>>> *business* and *operational* issues of asking some remote ISP >>>> to provide QoS service for you in any sort of scalable way >>> Fine, but that's completely orthogonal to whether the flow label is >>> a good idea or not. >> we don't care that no one can operationally use it. if it might sell >> one more router, let's kludge up the net a bit more. > Oh, please. There is a very straighforward tweak to RSVP to support > this i anxiously await a description the tweak which will provide "any way to deal with the *business* and *operational* issues of asking some remote ISP to provide QoS service for you in any sort of scalable way." randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekI3020843 for ; Wed, 13 Feb 2002 19:41:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JMbY019768 for ipng-dist; Wed, 13 Feb 2002 19:19:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HuFh019532 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11597 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13371 for ; Wed, 13 Feb 2002 20:17:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C34747D.A10A4C0F@hursley.ibm.com> Date: Thu, 03 Jan 2002 16:10:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Alex Conta Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> <3C2F5034.296F9A5E@txc.com> <3C32FD37.B79CDE36@hursley.ibm.com> <3C3377F8.6B9259AF@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 57 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, What you describe is the argument for the mutability of DSCPs (plus the need for out of band magic to restore the original value). I just don't see a win in having the same property, and resultant complexity, in the flow label as well. Brian Alex Conta wrote: > > Brian, > > Let's take one simple example: > > **begin of example > > let's consider three neighboring routers: R1, R2, R3, forwarding one > flow, characterized by > src=a, dst=b, flow-label=10000, from R1 to R2, to R3. > > Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). > Output interfaces are O1(R1), O2(R2), O3(R3). > > flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow > > If for R2's I2's classification engine, flow label value 10, is > significantloy better than 10000, R2 could notify R1, to change the > value 10000 to 10, when forwarding the flow on interface O1 towards I2. > R2 would also remember that on forwarding the flow internally from I2 to > O2, it has to restore the value to 10000. Consequetly, R2 would classify > the flow on I2, with value 10 instead of 10000, and forward it further > on O2 after changing the value 10 to value 10000. The flow would arrive > to R3 through I3, with flow label value 10000. > > **end of example. > > How is the mutability used by R1, and R2, affect R3 which is not part of > the signaling between R1, and R2? It does not! > > There are cases in which network (forwarding) devices are the best to > know what are the most optimum values for the flow label field. An > adequate flow setup mechanism can take care of any local flow label > value modification, and in the same time, restore flow label values to > eliminate the effects on the rest of the network. > > How would you ensure that such devices can maximize their potential, if > you do not leave any window of flexibility? > > Regards, > Alex > > Brian E Carpenter wrote: > > > > Alex, > > > > I don't agree. This restores the uncertainty that is preventing any > > current usage. > > > > Brian > > > > Alex Conta wrote: > > > > > > Making the field "immutable" by "default", but "mutable" when a router > > > is so instructed by a flow setup and flow processing mechanism is a > > > compromise that would satisfy all current and future possible cases. > > > > > > Therefore I think last sentence of the first paragraph > > > > > > All routers MUST pass the field on unchanged when forwarding a > > > packet. > > > > > > should be something like: > > > > > > All routers MUST leave the field unchanged, by default, when > > > forwarding a packet. > > > A specific flow setup/processing mechanism MAY give a "mutable" > > > character to the field, > > > by requesting routers, supporting the mechanism, to change the field > > > in certain ways. > > > Routers supporting such a mechanism MUST follow the steps indicated > > > by the flow > > > setup and flow processing mechanism. > > > > > > Alex > > > > > > Brian E Carpenter wrote: > > > > > > > > Taking Scott's suggestion, here's another try: > > > > > > > > I'd like to propose the following as the > > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to uniquely label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > [and delete Appendix A, which is unhelpful.] > > > > > > > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekH1020843 for ; Wed, 13 Feb 2002 19:41:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VUqP020413 for ipng-dist; Wed, 13 Feb 2002 19:31:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GF020208 for ; Wed, 13 Feb 2002 19:30:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16237 for ; Wed, 13 Feb 2002 19:18:11 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13538 for ; Wed, 13 Feb 2002 20:18:10 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: Brian E Carpenter , Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <3C348472.DD2BE3C9@hursley.ibm.com> <200201031709.g03H9ii13070@astro.cs.utk.edu> Message-Id: Date: Thu, 03 Jan 2002 09:13:37 -0800 Status: RO X-Status: X-Keywords: X-UID: 75 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The proposed new words for 2460 effectively say >> - you don't have to set it >> - you don't have to look at it >> - you mustn't change it >> I don't think encourages kludge significantly more than MBZ text, but it >> does allow for future usage. > as I see it, the proposed words let us get Flow Label off our > plates for now, which is good because we don't know what to do > with it anyway. maybe someday someone wall make a convincing > case for how to use it. and, if we do mbz, they can then write the rfc which changes that randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3hkFh021142 for ; Wed, 13 Feb 2002 19:43:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3hkWe021141 for ipng-dist; Wed, 13 Feb 2002 19:43:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HX020208 for ; Wed, 13 Feb 2002 19:31:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16318 for ; Wed, 13 Feb 2002 19:18:18 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14759 for ; Wed, 13 Feb 2002 20:18:17 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: Scott Bradner cc: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021922.g02JMSa10173@newdev.harvard.edu> References: <200201021922.g02JMSa10173@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 12:02:54 +0700 Message-ID: <2254.1010034174@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) From: Scott Bradner Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> | I do not believe that there is currently any way to deal with the | *business* and *operational* issues of asking some remote ISP | to provide QoS service for you in any sort of scalable way Yes, that's a real hard problem. But it isn't the current one. There are two separate issues here - how to communicate the information, and then how to use it. Now it is certainly true that communicating information is a waste of time if the information can't be used -- but it is also true that there's no point figuring out how to use the information if there's no way to communicate it. Since the operational issues are hard, without doubt, there's a certain reluctance to attempt to find a solution to it - and as long as that can be avoided by resorting to "we don't need it yet, there'd be no way to use it anyway", that is what will keep happening. But there is a simple solution which can arise - I, as a customer, can work out what path my packets will take (AS path), make contact with all of the ISPs represented, and offer to pay them large amounts of cash to make some specific set of my packets get to some particular destination(s) much more reliably with much lower than normal (congested) delay. That's easy to do (assuming the availability of the cash). It can be done today. However, assuming I do that, how are all those ISPs supposed to implement my request? Currently they'd have to do it using port number snooping, and so I'd have to be able to specify the port numbers in advance. But that's not always possible, nor is it a rational design in any case (it just happens to be all that's probably possible with IPv4). With IPv6 I can simply arrange to label all the "important" packets, so all those ISPs, who are only too willing to accept the cash, can actually manage to earn it. Now of course, as an operational method, the one above doesn't scale at all. But that's OK, it doesn't have to - it isn't being proposed as a method to be adopted by all and sundry. What it has done is provided the motivation for the mechanism to exist that allows the packet classification to be reasonable. Given that, the desire to make use of this will grow, and the operational community will be forced to do the work to figure out how to make it feasible economically. This may end up falling back to explicit agreements between sender (or receiver) of the data and everyone along the path (as in a credit card number included in the RSVP reservation packet, or the equivalent) Or it could be done based on settlements between ISPs, with the ISPs perhaps using the DSCP in packets passing between them to indicate: "I am being paid more to achieve better results for this packet, it will offset as more than a normal packet if you also give it priority" with most likely, each ISP subtracting a little from the amount offered as their own compensation, so the sender would need to offer more to get priority through a long path than through a short one (which is entirely reasonable). Or it could be something quite different. I don't think it is for this working group to answer that question. I do think it is reasonable though for enough basic mechanism to be provided that the ISPs can actually process the packets reasonably though - and I think now that we know enough about how the protocol parts of all this can be made to work (as aside from the operational issues) that it can be done now - and so provide the rationale for actually doing the operational work. Chasing down header chains looking for a transport header certainly isn't the answer (even considering ESP headers as transport for this purpose, which I'm not sure I'd regard as correct anyway). Unlike in IPv4, there's no guarantee that the transport header will even occur in the first fragment of a large packet in IPv6. While it might seem to be folly to send fragmented packets at the IP level and expect any kind of quality of service, with IPv6 it really isn't. If the amount of data that has to be delivered (whether that be transport data, or additional data from extra "headers" is larger) than will fit across the path MTU, then some kind of fragmentation is required. Whether that's done at the IPv6 layer, or at the transport layer (with some kind of segmented messages) doesn't really make any difference - all the pieces need to arrive for the data to be interpreted (that's an assumption). In a scenario like that, it makes perfect sense to use IPv6 fragmentation. And if that's done, the port numbers (or even ESP SPI) might not be in the first fragment. This cannot disqualify the packet from receiving any kind of QoS treatment. With IPv6 there is no need for it to do so either - everything needed to classify the packet is in the IPv6 header (addresses and flow label). That's all routers should be looking at, as it is all that they can reliably expect to actually find (even ignoring the issue of "find quickly"). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:40:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGL020843 for ; Wed, 13 Feb 2002 19:40:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q2El020106 for ipng-dist; Wed, 13 Feb 2002 19:26:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGL019898 for ; Wed, 13 Feb 2002 19:24:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12209 for ; Wed, 13 Feb 2002 19:18:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13906 for ; Wed, 13 Feb 2002 20:18:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.2.2.20020123095417.00a916a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Jan 2002 10:04:36 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: 3GPP Address Allocation Changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO X-Status: X-Keywords: X-UID: 892 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We recently received notice that the 3GPP has approved a change request to their GPRS architecture specification (23.060) based on the IPv6 WGs recommendations in draft-ietf-ipv6-3gpp-recommend-00.txt. The 3GPP has modified their address allocation mechanism to assign a prefix per primary PDP context, and to allow multiple identifiers to be used within that prefix. This was the most important change recommended in our document, and it eliminates the potential incompatibility between IPv6 privacy addresses and 3GPP. We believe that this change has been made retroactive to 3GPP release 99, so it will be included in all GPRS/UMTS releases that support IPv6 address autoconfiguration. I'd like to commend the 3GPP on their quick action to divert a potentially serious issue. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gnFh021083 for ; Wed, 13 Feb 2002 19:42:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gng2021082 for ipng-dist; Wed, 13 Feb 2002 19:42:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IKFh019704 for ; Wed, 13 Feb 2002 19:18:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11660 for ; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21756 for ; Wed, 13 Feb 2002 20:17:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C198@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian E Carpenter'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 3 Jan 2002 17:19:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 65 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The IANA assignment approach comes afterwards - once we get the > immutability property in the standard, we can use IANA assigned > values without further work. For diffserv we would use the > PHB ID values of RFC 3140, but there is no need to specify that > as part of the flow label definition; it comes free of charge. > => You need to make sure this is done before the fl text becomes standard, otherwise there will be conflicts between implementors who are not aware of IANA-based thoughts and the values that IANA may reserve. Hesham > > > > > > => Well, there is no requirement that the > flow label is > > > > > > globally unique. So this should work as long > as you use > > > > > > a unique value between 2 addresses. > > > > > > > > > > > > > > > > However, it's only useful for a subset of cases, > > > > > > > > => I didn't really understand what you mean by 'subset > > > > of cases'. > > > > > > It doesn't apply to the diffserv usage (where the label > > > is unique to a traffic class, not a flow or a pair of ports, > > > and may be IANA-registered) > > > > => That's why I didn't know what you meant :) > > I went back and re-read the draft but I couldn't > > see anything about IANA assignment. > > In fact I brought this up in the meeting but there > > was no support for the idea, so is this something > > you'd like to add or have I completely misunderstood > > something ? > > > > Hesham > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gbFh021067 for ; Wed, 13 Feb 2002 19:42:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gbCd021066 for ipng-dist; Wed, 13 Feb 2002 19:42:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcHB020453 for ; Wed, 13 Feb 2002 19:39:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05084 for ; Wed, 13 Feb 2002 19:19:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22300 for ; Wed, 13 Feb 2002 20:18:57 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020122050446.036870b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 05:24:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Issues raised during last call for DHCPv6 specification Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 854 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today. - Ralph Droms Open issues ----------- * We've experienced a proliferation of DHCPv6 options. Should all options *not* used in the base protocol be moved out to separate drafts? * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Other options: - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Should the Decline message have error codes defining the reason for the Decline? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. * Do we want to allow a client to request that more normal addresses be added to an IA, perhaps through use of the equivalent of the RTA option? * DHCP/DDNS interaction * Is the text in section 17.1.3 sufficient? Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - In the list of DHCP messages in section 7, fix Reconfigure to start Renew/Reply or Inform/Reply sequence (not Request/Reply) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix redundancy between sections 18.2.5 and 18.2.8 - Edit third paragraph of section 19.2 to delete references to IAs - In section 19.3.4, change "Rebind or Information-Request" to "Renew or Information-Request" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". - Edit section 22.14 to indicate that the server-address field is in the fixed-format part of the DHCP message, not the unicast option - Clarify the text in section 22.19 to indicate that the 'user class data' items are carried in the data area of the 'user class option' * Clarify text in section 13 about address selection based on source of message from client * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option * Modify SIP server option according to input from Henning Schulzrinne * Require that the DUID option appear before any IA options to improve processing efficiency * Require that the authentication option be first in th elist of options to reduce the work that a server must expend before discarding a message that fails authentication (reduces effect of denial of service attacks) * Clean up text specifying selection of address by server to insert into 'server-address' field * Clarify that a server MAY return fewer temporary addresses than requested by the client and MUST return AddrUnavail only if no temporary addresses are available * Clarify that a client MUST include all requested options in an ORO and MAY include suggested values by including specific options; also, the server MAY ignore suggestions from client and the client MUST use whatever the server returns * Clarify that a server MAY renew only some of the IAs sent by a client * Change DUID/VUID to have a length field to allow for longer IDs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGx020843 for ; Wed, 13 Feb 2002 19:41:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JX4t019778 for ipng-dist; Wed, 13 Feb 2002 19:19:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HrFh019506 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12169; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27898; Wed, 13 Feb 2002 19:17:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C34090C.2CC290C4@hursley.ibm.com> Date: Thu, 03 Jan 2002 08:32:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com Subject: Re: '::' address as destination References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, You are correct of course in terms of the wire protocol. The issue is that people using heterogeneous systems will be confused by inconsistency between implementations. Brian Erik Nordmark wrote: > > > Hello, > > > > RFC 2373 states that: > > "The unspecified address must not be used as the destination address > > of IPv6 packets or in IPv6 Routing Headers." > > > > However it seems that certain stacks are using this address in a different > > way. > > Yes, but I don't think there is an inherent conflict. > RFC 2373 specifies the behavior on the wire i.e. what is carried in > IPv6 packets. > Implementations might do various things at the API interface, but the > an implementation should ensure and :: doesn't appear as the destination in > the IPv6 packets it sends. > > > When '::' is the destination address: > > - some use the first available interface's address > > - some use the loopback address > > > > Is there a chance that one of these will become the acceptable norm? It > > would be interesting to know if the majority of implementations actually > > return an error for this case. > > I know that for Solaris we interpret :: at the API as the loopback > address. This was done to be consistent with the IPv4 Solaris code. > Unfortunately the introduction of the mechanism in the IPv4 Solaris code > was before my time. I don't think it existed in BSD 4.3tahoe but I haven't > checked. > > Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIP020843 for ; Wed, 13 Feb 2002 19:41:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3J3bh019749 for ipng-dist; Wed, 13 Feb 2002 19:19:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HsFh019514; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12187; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13359; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-Status: X-Keywords: X-UID: 52 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:44:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3i6Fh021159 for ; Wed, 13 Feb 2002 19:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3i5dD021158 for ipng-dist; Wed, 13 Feb 2002 19:44:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0H5020775 for ; Wed, 13 Feb 2002 19:39:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12462 for ; Wed, 13 Feb 2002 19:18:13 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28086 for ; Wed, 13 Feb 2002 19:18:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C3DF4BF.9DB23528@txc.com> Date: Thu, 10 Jan 2002 15:08:31 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <3C3DBBA4.AAD1A280@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0AC59D9CB57DA86218F62297" Status: RO X-Status: X-Keywords: X-UID: 370 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms0AC59D9CB57DA86218F62297 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit And engineers get the blame? Alex Brian E Carpenter wrote: > > Gerard.Gastaud@alcatel.fr wrote: > > > > and the user may refuse to pay because it idid not ask for the flow label that the malicious entity overwrote > > Indeed, and then the lawyers get involved. This is nothing new. > > Brian > > > gérard > > > > Brian E Carpenter on 10/01/2002 15:09:10 > > > > > > > > To: Subrata Goswami > > > > cc: ipng@sunroof.eng.sun.com(bcc: Gerard > > GASTAUD/FR/ALCATEL) > > > > > > > > Subject Re: Flow Label > > : > > > > > > --------------------------------------------------------------------------------------------------------------------------------- > > > > Subrata Goswami wrote: > > > > > > The main point is, if I am a provider and I get a packet, how can > > > I be sure that some malicious entity in the middle has not modified > > > the flow label so that it can avail of better QoS ? > > > > You can't, any more than you can be sure the DSCP hasn't changed, or that > > somebody isn't playing games with port numbers to fool your classifier. > > > > The ISP's defence against this is that more QoS will result in a higher bill. > > So the ISP actually doesn't care; they get paid accordingly. > > > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms0AC59D9CB57DA86218F62297 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTAyMDA4MzNaMCMGCSqGSIb3DQEJ BDEWBBTZ7BpNKiAVv7YkKGjj0KGMQZu2OjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgIEFCN5LPEEh1CmY4Z30E9Y77wI1ZHuzUbqq2VaJnpbeTDoR QEbHsLVJ6mGUH0R9altAEvXKIQGdiHxvDYC8ifdUnzEd1UrYKHuRvXOFbmfB+ZdRe/pAc5XW 4uJanCCE7EvBvtiNite1MIKY92mN44dQuNFziQIshS834UWbGuYI --------------ms0AC59D9CB57DA86218F62297-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIZ020843 for ; Wed, 13 Feb 2002 19:41:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dqaH020819 for ipng-dist; Wed, 13 Feb 2002 19:39:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGT020453 for ; Wed, 13 Feb 2002 19:38:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05003 for ; Wed, 13 Feb 2002 19:18:50 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15033 for ; Wed, 13 Feb 2002 20:18:49 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.8414.384615.139500@thomasm-u1.cisco.com> Date: Tue, 8 Jan 2002 08:39:58 -0800 (PST) To: Francis Dupont Cc: Pekka Nikander , Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081026.g08AQ6Q18134@givry.rennes.enst-bretagne.fr> References: <3C39FFB7.7000303@nomadiclab.com> <200201081026.g08AQ6Q18134@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Status: RO X-Status: X-Keywords: X-UID: 268 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > > So here's a most-likely crazy idea: why can't we > > treat the ingress filtering router like a CN which > > must first be sent a BU which it verifies in > > whatever manner the CN would? This already has a > > requirement to not be bound to mythical PKI's, > > etc. Given FMIP, the access routers are probably > > going to end up having to process things like BU's > > anyway. > > I was drifting into this direction myself. But how? > Introduce a new ICMP message saying: send me a BU > if you want to use HAO? > > => no, Michael's idea is to look at packets going through > access routers in order to find BUs (i.e. this is passive). > And if you'd like to use an active scheme, why not the > network access control? No, actually, it was to have the MN send the BU's directly to the access router. On a router the BU just has an additional effect of removing any restrictions on source addresses it will let through. Hence Pekka's question about use of ICMP was correct. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHx020843 for ; Wed, 13 Feb 2002 19:41:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VfWp020422 for ipng-dist; Wed, 13 Feb 2002 19:31:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GX020208 for ; Wed, 13 Feb 2002 19:30:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16806 for ; Wed, 13 Feb 2002 19:19:20 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14032 for ; Wed, 13 Feb 2002 20:19:20 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C500710.B2025CBF@hursley.ibm.com> Date: Thu, 24 Jan 2002 14:07:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michel Py Cc: JJ Behrens , Tony Hain , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification References: <2B81403386729140A3A899A8B39B046405DE6A@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 946 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nevertheless, it is not architecturally forbidden to subnet at /124 if you really want to - but doing so at /48 is more likely to be supported by all products. If I was an implementor, I certainly wouldn't worry if a /124 prefix kicked me onto a slow path, as long as prefixes from /3 to /64 were handled optimally. Brian Michel Py wrote: > > > JJ Behrens wrote: > > Please forgive me for being a newbie, but it seems wise to > > allow subnetting of the lower 64 bits. Afterall, it would > > be terrible if my dialup ISP assigned a /64 to me, and I > > had to rely on some IPv6 mythical NAT to do subnetting! > > I don't think this will happen. IPv6 ISPs currently assign > /48 prefixes (see www.freenet6.net for example) which gives > you 65536 subnets to play. Besides, doing subnets on a dial-up > connection looks rather overkill to me. > > Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:45:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3jkFh021207 for ; Wed, 13 Feb 2002 19:45:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3jkRt021206 for ipng-dist; Wed, 13 Feb 2002 19:45:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gl020775 for ; Wed, 13 Feb 2002 19:39:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12475 for ; Wed, 13 Feb 2002 19:18:13 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28095 for ; Wed, 13 Feb 2002 19:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.2.2.20020110123646.03743350@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 10 Jan 2002 13:01:55 -0500 To: jarno.rajahalme@nokia.com From: Margaret Wasserman Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198092@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO X-Status: X-Keywords: X-UID: 369 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, At 09:51 AM 1/10/02 , jarno.rajahalme@nokia.com wrote: >I just reviewed the related threads on this list and the proposed text >quoted below seems to have unanimous support (less ~2 persons) on the >list. I support this text as well, but have a worry about it not stating >in which context flow label, when set, is meaningful. I do not think that we should define this as part of the IPv6 base specification. The semantics of the flow label (including how it can (or can't) be used to identify a flow) should be specified as part of any flow management mechanism that uses the IPv6 flow label field. This may differ from one mechanism to another. I do not think that the base IPv6 specs should place any constraints on how flow management mechanisms can use the flow label. NOTE: I realize that immutability is a constraint. I have agreed to compromise on that one point. >The text below >says that the label is used to "label sets of packets". In the SLC >meeting I presented our proposal to consider the (Source Address, Flow >Label, Destination Address) 3-tuple to classify the "set of packets". It would be okay with me to take out the words "sets of", if you believe that this is confusing without further context. I do not think that we want to specify, as part of IPv6, that a 3-tuple can be used to identify a flow. I have two reasons for this: - The 3-tuple that you describe is not sufficient to unambiguously identify a flow without further specification of how/when flow labels can be re-used by hosts. - How to classify a flow shouldn't be part of the base IPv6 specification -- it is specific to a flow management mechanism. [...] >Also, not stating >how the "set" can be classified will not help HW-designers to do the >right thing with their designs ASAP. Can you give examples of "right things" that could be done if we make this change that could not be done if we don't make this change? >Text including the S+D addresses would be like (the second sentence is >added, no other changes): > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to label sets of packets. A packet can be classified to a set > with the source address, flow label, destination address triplet. [...] >So, for those who have hummed yes to the text below, how many of you >would oppose modifying it to include mentioning the fields used for >classification, and why? I strongly object to mentioning "the fields used for classification" as part of the base IPv6 specs. I think that flow management mechanisms and their semantics (including flow classification mechanism(s)) should be specified in separate documents (and by separate WGs). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHd020843 for ; Wed, 13 Feb 2002 19:41:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VbO8020418 for ipng-dist; Wed, 13 Feb 2002 19:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GJ020208 for ; Wed, 13 Feb 2002 19:30:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16194 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28045 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C36391C.A4DF3C3F@eng.sun.com> Date: Fri, 04 Jan 2002 15:22:04 -0800 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <3C348636.DB130121@hursley.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 156 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > The one acronym summary of kre's point is: SLA. I'd venture > to say that no QoS solution will ever work in the absence of > an SLA. And guess what, the IETF doesn't discuss business > models and SLAs. The most we can do is standardise tools > that can be deployed to support SLAs. > > So, I think it's time for a hum on this one (the simple > update to 2460 that Scott and I at least seem to agree > on). > I humm for it. It's time to move on. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekID020843 for ; Wed, 13 Feb 2002 19:41:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JiAi019784 for ipng-dist; Wed, 13 Feb 2002 19:19:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IDFh019660 for ; Wed, 13 Feb 2002 19:18:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12290 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06924 for ; Wed, 13 Feb 2002 20:17:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <008101c1947e$4395b780$7e6015ac@T23KEMPF> From: "James Kempf" To: "Brian E Carpenter" , , "Richard Carlson" References: <200201021922.g02JMSa10173@newdev.harvard.edu> <2254.1010034174@brandenburg.cs.mu.OZ.AU> <4.3.2.7.2.20020103110729.00b16470@atalanta.ctd.anl.gov> Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] Date: Thu, 3 Jan 2002 09:44:16 -0800 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Status: RO X-Status: X-Keywords: X-UID: 78 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hum as well. jak ----- Original Message ----- From: "Richard Carlson" To: "Brian E Carpenter" ; Sent: Thursday, January 03, 2002 9:08 AM Subject: Re: Where are the WG chairs when we need them? [was Re: Flow Label] > I hum for this. > > Rich > > At 05:26 PM 1/3/02 +0100, Brian E Carpenter wrote: > >The one acronym summary of kre's point is: SLA. I'd venture > >to say that no QoS solution will ever work in the absence of > >an SLA. And guess what, the IETF doesn't discuss business > >models and SLAs. The most we can do is standardise tools > >that can be deployed to support SLAs. > > > >So, I think it's time for a hum on this one (the simple > >update to 2460 that Scott and I at least seem to agree > >on). > > > > Brian > > > >Robert Elz wrote: > > > > > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > > > From: Scott Bradner > > > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > > > > > | I do not believe that there is currently any way to deal with the > > > | *business* and *operational* issues of asking some remote ISP > > > | to provide QoS service for you in any sort of scalable way > > > > > > Yes, that's a real hard problem. But it isn't the current one. > > > > > > There are two separate issues here - how to communicate the information, > > > and then how to use it. > > > > > > Now it is certainly true that communicating information is a waste of time > > > if the information can't be used -- but it is also true that there's no > > > point figuring out how to use the information if there's no way to > > communicate > > > it. > > > > > > Since the operational issues are hard, without doubt, there's a certain > > > reluctance to attempt to find a solution to it - and as long as that can > > > be avoided by resorting to "we don't need it yet, there'd be no way to use > > > it anyway", that is what will keep happening. > > > > > > But there is a simple solution which can arise - I, as a customer, can work > > > out what path my packets will take (AS path), make contact with all of the > > > ISPs represented, and offer to pay them large amounts of cash to make some > > > specific set of my packets get to some particular destination(s) much more > > > reliably with much lower than normal (congested) delay. That's easy to do > > > (assuming the availability of the cash). It can be done today. > > > > > > However, assuming I do that, how are all those ISPs supposed to implement > > > my request? Currently they'd have to do it using port number snooping, > > > and so I'd have to be able to specify the port numbers in advance. But > > > that's not always possible, nor is it a rational design in any case (it > > > just happens to be all that's probably possible with IPv4). With IPv6 > > > I can simply arrange to label all the "important" packets, so all those > > > ISPs, who are only too willing to accept the cash, can actually manage to > > > earn it. > > > > > > Now of course, as an operational method, the one above doesn't scale at > > all. > > > But that's OK, it doesn't have to - it isn't being proposed as a method > > > to be adopted by all and sundry. What it has done is provided the > > > motivation for the mechanism to exist that allows the packet classification > > > to be reasonable. Given that, the desire to make use of this will grow, > > > and the operational community will be forced to do the work to figure out > > > how to make it feasible economically. > > > > > > This may end up falling back to explicit agreements between sender > > > (or receiver) of the data and everyone along the path (as in a credit > > > card number included in the RSVP reservation packet, or the equivalent) > > > Or it could be done based on settlements between ISPs, with the ISPs > > > perhaps using the DSCP in packets passing between them to indicate: > > > "I am being paid more to achieve better results for this packet, it will > > > offset as more than a normal packet if you also give it priority" with > > > most likely, each ISP subtracting a little from the amount offered as > > > their own compensation, so the sender would need to offer more to get > > > priority through a long path than through a short one (which is entirely > > > reasonable). Or it could be something quite different. > > > > > > I don't think it is for this working group to answer that question. > > > I do think it is reasonable though for enough basic mechanism to be > > > provided that the ISPs can actually process the packets reasonably > > > though - and I think now that we know enough about how the protocol > > > parts of all this can be made to work (as aside from the operational > > > issues) that it can be done now - and so provide the rationale for > > > actually doing the operational work. > > > > > > Chasing down header chains looking for a transport header certainly > > > isn't the answer (even considering ESP headers as transport for this > > > purpose, which I'm not sure I'd regard as correct anyway). Unlike > > > in IPv4, there's no guarantee that the transport header will even occur > > > in the first fragment of a large packet in IPv6. While it might seem to > > > be folly to send fragmented packets at the IP level and expect any kind > > > of quality of service, with IPv6 it really isn't. If the amount of > > > data that has to be delivered (whether that be transport data, or > > > additional data from extra "headers" is larger) than will fit across the > > > path MTU, then some kind of fragmentation is required. Whether that's > > > done at the IPv6 layer, or at the transport layer (with some kind of > > > segmented messages) doesn't really make any difference - all the pieces > > > need to arrive for the data to be interpreted (that's an assumption). > > > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > > > And if that's done, the port numbers (or even ESP SPI) might not be in > > > the first fragment. This cannot disqualify the packet from receiving > > > any kind of QoS treatment. With IPv6 there is no need for it to do so > > > either - everything needed to classify the packet is in the IPv6 header > > > (addresses and flow label). That's all routers should be looking at, as > > > it is all that they can reliably expect to actually find (even ignoring the > > > issue of "find quickly"). > > > > > > kre > > > >-- > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >Brian E Carpenter > >Distinguished Engineer, Internet Standards & Technology, IBM > >On assignment at the IBM Zurich Laboratory, Switzerland > >Board Chairman, Internet Society http://www.isoc.org > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > ------------------------------------ > > Richard A. Carlson e-mail: RACarlson@anl.gov > Network Research Section phone: (630) 252-7289 > Argonne National Laboratory fax: (630) 252-4021 > 9700 Cass Ave. S. > Argonne, IL 60439 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHp020843 for ; Wed, 13 Feb 2002 19:41:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JSPv019776 for ipng-dist; Wed, 13 Feb 2002 19:19:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IAFh019647 for ; Wed, 13 Feb 2002 19:18:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12260 for ; Wed, 13 Feb 2002 19:17:56 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13409 for ; Wed, 13 Feb 2002 20:17:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: "Bill Strahm" To: "Brian E Carpenter" , Subject: RE: Where are the WG chairs when we need them? [was Re: Flow Label] Date: Thu, 3 Jan 2002 11:16:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C348636.DB130121@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Status: RO X-Status: X-Keywords: X-UID: 88 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'll hum for this... it is a long time coming... By the way, where is the RFC describing the monitoring and counting of hums anyway Please lets not make something more complex than MPLS here Bill -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter Sent: Thursday, January 03, 2002 8:27 AM To: ipng@sunroof.eng.sun.com Subject: Where are the WG chairs when we need them? [was Re: Flow Label] The one acronym summary of kre's point is: SLA. I'd venture to say that no QoS solution will ever work in the absence of an SLA. And guess what, the IETF doesn't discuss business models and SLAs. The most we can do is standardise tools that can be deployed to support SLAs. So, I think it's time for a hum on this one (the simple update to 2460 that Scott and I at least seem to agree on). Brian Robert Elz wrote: > > Date: Wed, 2 Jan 2002 14:22:28 -0500 (EST) > From: Scott Bradner > Message-ID: <200201021922.g02JMSa10173@newdev.harvard.edu> > > | I do not believe that there is currently any way to deal with the > | *business* and *operational* issues of asking some remote ISP > | to provide QoS service for you in any sort of scalable way > > Yes, that's a real hard problem. But it isn't the current one. > > There are two separate issues here - how to communicate the information, > and then how to use it. > > Now it is certainly true that communicating information is a waste of time > if the information can't be used -- but it is also true that there's no > point figuring out how to use the information if there's no way to communicate > it. > > Since the operational issues are hard, without doubt, there's a certain > reluctance to attempt to find a solution to it - and as long as that can > be avoided by resorting to "we don't need it yet, there'd be no way to use > it anyway", that is what will keep happening. > > But there is a simple solution which can arise - I, as a customer, can work > out what path my packets will take (AS path), make contact with all of the > ISPs represented, and offer to pay them large amounts of cash to make some > specific set of my packets get to some particular destination(s) much more > reliably with much lower than normal (congested) delay. That's easy to do > (assuming the availability of the cash). It can be done today. > > However, assuming I do that, how are all those ISPs supposed to implement > my request? Currently they'd have to do it using port number snooping, > and so I'd have to be able to specify the port numbers in advance. But > that's not always possible, nor is it a rational design in any case (it > just happens to be all that's probably possible with IPv4). With IPv6 > I can simply arrange to label all the "important" packets, so all those > ISPs, who are only too willing to accept the cash, can actually manage to > earn it. > > Now of course, as an operational method, the one above doesn't scale at all. > But that's OK, it doesn't have to - it isn't being proposed as a method > to be adopted by all and sundry. What it has done is provided the > motivation for the mechanism to exist that allows the packet classification > to be reasonable. Given that, the desire to make use of this will grow, > and the operational community will be forced to do the work to figure out > how to make it feasible economically. > > This may end up falling back to explicit agreements between sender > (or receiver) of the data and everyone along the path (as in a credit > card number included in the RSVP reservation packet, or the equivalent) > Or it could be done based on settlements between ISPs, with the ISPs > perhaps using the DSCP in packets passing between them to indicate: > "I am being paid more to achieve better results for this packet, it will > offset as more than a normal packet if you also give it priority" with > most likely, each ISP subtracting a little from the amount offered as > their own compensation, so the sender would need to offer more to get > priority through a long path than through a short one (which is entirely > reasonable). Or it could be something quite different. > > I don't think it is for this working group to answer that question. > I do think it is reasonable though for enough basic mechanism to be > provided that the ISPs can actually process the packets reasonably > though - and I think now that we know enough about how the protocol > parts of all this can be made to work (as aside from the operational > issues) that it can be done now - and so provide the rationale for > actually doing the operational work. > > Chasing down header chains looking for a transport header certainly > isn't the answer (even considering ESP headers as transport for this > purpose, which I'm not sure I'd regard as correct anyway). Unlike > in IPv4, there's no guarantee that the transport header will even occur > in the first fragment of a large packet in IPv6. While it might seem to > be folly to send fragmented packets at the IP level and expect any kind > of quality of service, with IPv6 it really isn't. If the amount of > data that has to be delivered (whether that be transport data, or > additional data from extra "headers" is larger) than will fit across the > path MTU, then some kind of fragmentation is required. Whether that's > done at the IPv6 layer, or at the transport layer (with some kind of > segmented messages) doesn't really make any difference - all the pieces > need to arrive for the data to be interpreted (that's an assumption). > In a scenario like that, it makes perfect sense to use IPv6 fragmentation. > And if that's done, the port numbers (or even ESP SPI) might not be in > the first fragment. This cannot disqualify the packet from receiving > any kind of QoS treatment. With IPv6 there is no need for it to do so > either - everything needed to classify the packet is in the IPv6 header > (addresses and flow label). That's all routers should be looking at, as > it is all that they can reliably expect to actually find (even ignoring the > issue of "find quickly"). > > kre -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIJ020843 for ; Wed, 13 Feb 2002 19:41:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q31p020107 for ipng-dist; Wed, 13 Feb 2002 19:26:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGT019898 for ; Wed, 13 Feb 2002 19:24:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11818 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13513 for ; Wed, 13 Feb 2002 20:18:07 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.17209.452224.850919@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 09:28:25 -0800 (PST) To: Scott Bradner Cc: moore@cs.utk.edu, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200201021620.g02GKju09321@newdev.harvard.edu> References: <200201021620.g02GKju09321@newdev.harvard.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Status: RO X-Status: X-Keywords: X-UID: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > > > why do folk think that ISPs half way around the world would find it useful > > > to know what the sending computer wanted for QoS? > > > because the sending computer (application) knows the nature of the traffic? > > without a way for the remote ISP to get paid for treating the traffic in > some way other then best-effort I do not see that this helps Are you claiming that RFC 3182 (nee 2752) is inadequate for interdomain? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekGf020843 for ; Wed, 13 Feb 2002 19:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dx4Q020826 for ipng-dist; Wed, 13 Feb 2002 19:39:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGJ020453 for ; Wed, 13 Feb 2002 19:38:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04855 for ; Wed, 13 Feb 2002 19:18:40 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07265 for ; Wed, 13 Feb 2002 20:18:39 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Brian E Carpenter Cc: Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jan 2002 10:02:46 -0500 Message-Id: <20020111150246.D34077B4B@berkshire.research.att.com> Status: RO X-Status: X-Keywords: X-UID: 384 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E Carpenter writes: >Indeed. All of this is the same for the DSCP actually, and the >assumption is that operators will protect themselves with >admission control. > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) > Right. The question now is how to do that. I was about to agree strongly with the "must send as zero if not a flow, routers must not modify" until I started thinking along these lines. What should a border router do with a packet that doesn't meet its constraints? I only see three choices: reset the flow label to something locally acceptable, drop the packet, or tunnel. But dropping the packet means that flow labels can only be used for flows that stay within a particular flow label domain, and the tunneling path leads to madness. (Well, perhaps to MPLS, but I don't think we want to go down that rathole now.) I'm forced to conclude that we have two choices: either we give up on flow labels entirely, or we permit them to be modified en route. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHJ020843 for ; Wed, 13 Feb 2002 19:41:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JgEC019782 for ipng-dist; Wed, 13 Feb 2002 19:19:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HsFh019525 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11592 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06905 for ; Wed, 13 Feb 2002 20:17:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Thu, 3 Jan 2002 16:14:40 -0800 Nokia Silicon Valley Messaging Protection Message-Id: <4.3.2.7.2.20020103161323.0272e488@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jan 2002 16:13:52 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft IPv6 Working Group minutes Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 109 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft minutes from the IPv6 sessions at the Salt Lake City IETF are available at: http://playground.sun.com/pub/ipng/html/minutes/ipv6-minutes-dec2001.txt Presentations are available at: http://playground.sun.com/ipng/meetings.html Please send me comments and corrections. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:47:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3l9Fh021256 for ; Wed, 13 Feb 2002 19:47:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3l9R9021255 for ipng-dist; Wed, 13 Feb 2002 19:47:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0GB020775 for ; Wed, 13 Feb 2002 19:39:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12739 for ; Wed, 13 Feb 2002 19:19:06 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07453 for ; Wed, 13 Feb 2002 20:19:05 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 23 Jan 2002 11:18:18 -0800 (PST) From: JJ Behrens To: Tony Hain cc: Michel Py , Keith Moore , Irina Dayal , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Addr/Prefix clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 925 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Tony Hain > Keith is technically correct, a site may choose to subnet the low 64 > bits. It might be unwise to do so, because they would be giving up the > autoconfiguration & privacy capabilities, but that is their choice. They > may also find acquiring routing hardware that works beyond the 64 bit > prefix to be a challenge ... Please forgive me for being a newbie, but it seems wise to allow subnetting of the lower 64 bits. Afterall, it would be terrible if my dialup ISP assigned a /64 to me, and I had to rely on some IPv6 mythical NAT to do subnetting! A /64 is really quite a lot of address space to subnet; without the ability to subnet, a /64 seems wasteful. In response to the address autoconfiguration using MAC addresses argument, address autoconfiguration can be done using something other than the MAC address in those circumstances. The fact that neighbor solicitations are used to verify the uniqueness of tentative addresses is proof enough that MAC addresses were never meant to be the end all and be all of address autoconfiguration. -jj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3fdFh020974 for ; Wed, 13 Feb 2002 19:41:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3fdZX020972 for ipng-dist; Wed, 13 Feb 2002 19:41:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fr020775 for ; Wed, 13 Feb 2002 19:39:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12279 for ; Wed, 13 Feb 2002 19:17:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13418 for ; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 2 Jan 2002 11:16:00 -0500 (EST) From: Scott Bradner Message-Id: <200201021616.g02GG0o09266@newdev.harvard.edu> To: brian@hursley.ibm.com, sob@harvard.edu Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com, mat@cisco.com, perry@wasabisystems.com Status: RO X-Status: X-Keywords: X-UID: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No, I don't agree that we can leave the vagueness in 2460. IMNSHO we > should either accept the rewording we've hammered out (which carefully > doesn't say anything about QOS) or change it to MBZ. I'm fine with the new wording - I'm just not fine with the assumption that we have any idea what to do with the static info > If A is a customer of ISP X in some distant country, there might be (and > I am only saying might be) an SLA in place that says "whenever you get > a packet from or to A, with 1234 in its flow label, give it such a level > of service." > > I'm not saying that this is especially likely or plausible, but it > certainly isn't impossible. scales well :-) Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHH020843 for ; Wed, 13 Feb 2002 19:41:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PmSw020095 for ipng-dist; Wed, 13 Feb 2002 19:25:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGF019898 for ; Wed, 13 Feb 2002 19:24:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12237 for ; Wed, 13 Feb 2002 19:18:57 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15065 for ; Wed, 13 Feb 2002 20:18:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-mProtect: Wed, 23 Jan 2002 10:41:05 -0800 Nokia Silicon Valley Messaging Protection Message-Id: <4.3.2.7.2.20020123103524.02dfdea0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 10:40:49 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: RO X-Status: X-Keywords: X-UID: 922 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-04.txt Pages : 79 Date : 15-Jan-02 This document will replace RFC2592 that is an Informational RFC. The changes from RFC2592 are listed in section 17 of the internet draft. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on February 6, 2002. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:43:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3hDFh021108 for ; Wed, 13 Feb 2002 19:43:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3hDvL021107 for ipng-dist; Wed, 13 Feb 2002 19:43:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXHP019898 for ; Wed, 13 Feb 2002 19:25:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12007 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02576 for ; Wed, 13 Feb 2002 19:18:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <014801c19f2a$b7abb190$38a5fe81@dicao> From: "Yong-Seung Bae" To: "IPng Members" Subject: Layer violation Date: Thu, 17 Jan 2002 16:43:55 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0145_01C19F76.27192080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Status: RO X-Status: X-Keywords: X-UID: 627 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0145_01C19F76.27192080 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIG1lbWJlcnMNCkkgaGF2ZSBiZWVuIHF1ZXN0aW9uIGFib3V0IGxheWVyIHZpb2xhdGlvbi4u Lg0KDQpXaGF0IGlzIGxheWVyIHZpb2xhdGlvbnM/DQpXaGF0IGtpbmQgb2YgbGF5ZXIgdmlvbGF0 aW9ucyB0aGF0IGlzIGludGVuZGVkIHRvIHN0b3Aocm91dGVyIG9yIGhvc3QpPw0KV2hhdCB0aGUg cHVycG9zZSBvZiB0aG9zZSBsYXllciB2aW9sYXRpb25zIGlzPw0KDQpUaGFua3MNCkplcmVtaWFo DQo= ------=_NextPart_000_0145_01C19F76.27192080 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxG T05UIHNpemU9Mj5IaSwgbWVtYmVyczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkg aGF2ZSBiZWVuIHF1ZXN0aW9uIGFib3V0IGxheWVyIHZpb2xhdGlvbi4uLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PldoYXQgaXMgbGF5ZXIgdmlvbGF0aW9ucz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5XaGF0IGtpbmQgb2YgbGF5ZXIgdmlvbGF0aW9ucyB0aGF0IGlzIGludGVuZGVkIHRvIHN0b3Ao cm91dGVyIA0Kb3IgaG9zdCk/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2hhdCB0 aGUgcHVycG9zZSBvZiB0aG9zZSBsYXllciB2aW9sYXRpb25zIGlzPzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRo YW5rczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkplcmVtaWFoPC9GT05UPjwvRElW PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0145_01C19F76.27192080-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:44:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3iFFh021167 for ; Wed, 13 Feb 2002 19:44:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3iF6L021166 for ipng-dist; Wed, 13 Feb 2002 19:44:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fl020775 for ; Wed, 13 Feb 2002 19:39:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12614 for ; Wed, 13 Feb 2002 19:18:48 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02692 for ; Wed, 13 Feb 2002 19:18:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: 21 Jan 2002 12:35:05 -0000 Message-ID: <20020121123505.22487.qmail@mailFA8.rediffmail.com> MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Query About MLD Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0LCYA2Q015665 Status: RO X-Status: X-Keywords: X-UID: 812 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir/Madam, I have some queries regarding MLD (Multicast Listener Discovery). I am a beginner in IPv6.So, my question may look very simple for you. Why MLD ( Multicast Listener Discovery) message are sent for Sloicited-Node multicast address ? Regards, Ramakrishnan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3f9Fh020908 for ; Wed, 13 Feb 2002 19:41:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3f9BI020906 for ipng-dist; Wed, 13 Feb 2002 19:41:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0GR020775 for ; Wed, 13 Feb 2002 19:39:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12502 for ; Wed, 13 Feb 2002 19:18:23 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14796 for ; Wed, 13 Feb 2002 20:18:22 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201142232.RAA22568@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IP Version 6 Addressing Architecture to Draft Standard Reply-to: iesg@ietf.org Date: Mon, 14 Jan 2002 17:32:25 -0500 Status: RO X-Status: X-Keywords: X-UID: 522 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Version 6 Working Group to consider 'IP Version 6 Addressing Architecture' as a Draft Standard, replacing RFC2373, currently a Proposed Standard. The WG originally asked to advance this document to Draft standard in 1998, but the IESG pushed back on advancement pending more implementation experience on some aspects of multicast scoping and on concerns over the readiness of advancing the companion "Aggregatable Global Unicast Address Format" document with which it had been paired. Since that time, additional interoperability has been demonstrated, and the document is being advanced independent of the other document. There was continued support in the WG for advancement of this document. A new IETF Last Call was held in Decemeber, 2000. Comments and IESG discussion resulting from the Last Call resulted in a number of document changes. Those changes included: - removing the Format Prefix (to clarify that implementations should not build in knowledge about any prefixes except ones that are explicitly listed in the specification), - making it clear that all address space was to be treated as global unicast, except in those specific cases where other definitions already existed, - making it clear that reference to RFC 2374 (An Aggregatable Global Unicast Address Format) was an example, as address assignment policy is under the domain of the RIRs A full list of changes can be found in the changes section of the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 28, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt Imnplementation Report can be viewed at http://www.ietf.cnri.reston.va.us/IESG/Implementations/address-architecture.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gHFh021043 for ; Wed, 13 Feb 2002 19:42:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3gHN0021042 for ipng-dist; Wed, 13 Feb 2002 19:42:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gf020775 for ; Wed, 13 Feb 2002 19:39:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12465 for ; Wed, 13 Feb 2002 19:18:13 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02463 for ; Wed, 13 Feb 2002 19:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201111354.IAA14496@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-00.txt Date: Fri, 11 Jan 2002 08:54:56 -0500 Status: RO X-Status: X-Keywords: X-UID: 383 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Host to Router Load Sharing Author(s) : B. Hinden Filename : draft-ietf-ipv6-host-load-sharing-00.txt Pages : 4 Date : 10-Jan-02 This document defines a change to IPv6 Neighbor Discovery that IPv6 hosts can use to load share their outgoing traffic between multiple default routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-host-load-sharing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020110150256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150256.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:46:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3kEFh021226 for ; Wed, 13 Feb 2002 19:46:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3kE52021225 for ipng-dist; Wed, 13 Feb 2002 19:46:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gd020775 for ; Wed, 13 Feb 2002 19:39:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12281 for ; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06923 for ; Wed, 13 Feb 2002 20:17:55 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C331B96.94FF2BF3@hursley.ibm.com> Date: Wed, 02 Jan 2002 15:39:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: perry@wasabisystems.com, ipng@sunroof.eng.sun.com, mat@cisco.com Subject: Re: Flow Label References: <200201021342.g02Dg9Q08853@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner wrote: > > Brian sez: > > In the intserv case, it is no different. In the diffserv case, the presumption > > is that we would use IANA-assigned, globally meaningful values, that are > > specific to a desired QOS treatment rather than to any individual traffic flow. > > The implementation details (including the DSCP value and router configurations) > > may differ from ISP to ISP, but the flow label bits convey end to end > > semantics. This is more powerful than port numbers whose semantics are poor at > > best for QOS purposes, and it works when the port numbers are invisible. > > this still begs the question > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? s/computer/customer/ If A is a customer of ISP X in some distant country, there might be (and I am only saying might be) an SLA in place that says "whenever you get a packet from or to A, with 1234 in its flow label, give it such a level of service." I'm not saying that this is especially likely or plausible, but it certainly isn't impossible. > > at least in the case of difserv if an ISP gets a DSCP there is some > implied authorization by the previous network (ISP or enterprise) - how > does authorization happen in the case of imutable globally meaningful > values? In both cases you need an SLA in place - with the upstream ISP, or with the ultimate traffic source or destination. I agree that it certainly doesn't happen because the ISP is a nice guy. > > I see no reason to believe that such a field will be any use whatsoever > in providing QoS in the Internet - and it is redundant in an enterprise > because the enterprise can decide to not change the DSCP field I bet I could construct an enterprise scenario where you could use it, but you're basically correct, the only real use is when you jump over intermediate ISPs and need a field that hasn't been changed en route. > > unless there is some hint of a way for this change to serve any useful > purpose we should just leave things as they are No, I don't agree that we can leave the vagueness in 2460. IMNSHO we should either accept the rewording we've hammered out (which carefully doesn't say anything about QOS) or change it to MBZ. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekHX020843 for ; Wed, 13 Feb 2002 19:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3df9r020817 for ipng-dist; Wed, 13 Feb 2002 19:39:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcG1020453 for ; Wed, 13 Feb 2002 19:38:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04963 for ; Wed, 13 Feb 2002 19:18:47 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07333 for ; Wed, 13 Feb 2002 20:18:45 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Tue, 8 Jan 2002 12:48:35 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Pekka Nikander , Michael Thomas , Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081028.g08ASQQ18161@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 262 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 8 Jan 2002, Francis Dupont wrote: > In your previous mail you wrote: > > Also, this would get more difficult in the case of multiple, changing > paths (multihoming). > > => as multi-homing is a place we could want to use home address options > this is a real issue... I've always thought using Home Address option as a way of getting around ingress filtering checks in multihoming is like "if words fail you, mumble!" -approach. Much more analysis is needed IMO before HAO is to be used outside of MIPv6 context. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:46:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3kcFh021241 for ; Wed, 13 Feb 2002 19:46:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3kcND021240 for ipng-dist; Wed, 13 Feb 2002 19:46:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXHV019898 for ; Wed, 13 Feb 2002 19:26:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11762 for ; Wed, 13 Feb 2002 19:18:05 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21839 for ; Wed, 13 Feb 2002 20:18:04 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <03de01c1982e$9cb9e2b0$01000001@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: "Ramakrishnan" Cc: References: <20020108042944.15886.qmail@mailweb16.rediffmail.com> Subject: Re: Query About IPv6 Date: Tue, 8 Jan 2002 18:24:10 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Status: RO X-Status: X-Keywords: X-UID: 256 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1. The routing table under IPv6 is very similar to that of IPv4. For example, In my cisco router, one of the route entries is as following(see the Cisco reference for detail): B 3FFE:2401::/32 [20/3] via FE80::806B:F0FE, Tunnel4, 00:37:14/never In this entry: B - BGP protocol 3FFE:2401::/32 - prefix of the remote network [20/3] - The first is the administrative distance of the information source; the second number is the metric for the route via FE80::806B:F0FE - next router Tunnel4 - interface to remote network 00:37:14/never - route update time / route expire time And in linux, the route table entry consists of "Destination , Next Hop, Flags, Metric, Ref, Use, Iface" , almost the same as IPv4. 2. The link local address is generated automaticlly when u config the interface to support Ipv6. and it can be added manually to more than one( I have tried in RH Linux7, but don't know the reason to have more link local address) . Happy new year! : ) Zhang Hong ----- Original Message ----- From: "Ramakrishnan" To: Sent: Tuesday, January 08, 2002 12:29 PM Subject: Query About IPv6 > > Dear Sir/Madam, > > I have some queries regarding IPv6. I am still in the learning stage. So, my question may look very simple for you, but if you answer it, that will help me a lot. > > 1. What are the entries in the routing table under IPv6? > 2. Can an Interface have more than one link local address? > > I'll be looking forward for the answers... > > regards, > Ramakrishnan. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:45:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3jLFh021199 for ; Wed, 13 Feb 2002 19:45:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3jKLv021198 for ipng-dist; Wed, 13 Feb 2002 19:45:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcH5020453 for ; Wed, 13 Feb 2002 19:39:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04734 for ; Wed, 13 Feb 2002 19:18:32 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07204 for ; Wed, 13 Feb 2002 20:18:31 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: Alex Conta cc: Subrata Goswami , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C3A017F.8FE859EB@txc.com> References: <3C3A017F.8FE859EB@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2002 10:08:28 +0700 Message-ID: <3342.1010545708@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 286 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta Message-ID: <3C3A017F.8FE859EB@txc.com> | One of the comments pro "immutability" was that you cannot trust the | flow label if it is not "immutable". I didn't ever see that argument. What I saw was that you can't rely upon it if it isn't - but not from the point of view of the recipient, from the point of view of the sender. That is, if the value might be changed to any random thing, what's the point of setting it all, ever? It would just be meaningless bits (imagine a router forwarding a packet through an encrypting tunnel, and seeing some mutable bits - ones it is allowed to alter - and filling them with a random value in order to make cryptanalysis more difficult). | Current or future flow setup and flow processing mechanisms, do now, or | will, in the future, | KNOW BEST the micro-details of the flow label usage. Therefore | responsibility of the immutability/mutability of the flow label value | should stay ALONE with those mechanisms. I think in this case, you really favour making the field immutable, but unverified. If it were truly mutable, it would never be able to be used for any of those uses, as no-one could ever rely upon any value they set remaining intact to the point where it was supposed to be used (the "router" in my previous paragraph might be a link level bridge type object - even imagine a NIC that sees this mutable field and uses it to send to the destination a count of the number of times it deferred because of a busy link before sending the packet...) If some future spec wants to make the field mutable, then as long as we have not done anything silly (like modify the current AH rules) to prevent it, then that spec will be able to do that - and with a good chance of being able to rely upon the value only being changed as the future new spec actually says should happen. | By leaving mutability alone, possible issues with checksum, and AH | calculation can be really forgotten, or ignored. This amounts to "make it immutable, don't change AH, and explain in the doc that AH explicitly doesn't include the flow label, to leave open the possibility that some later spec might specify conditions under which the field can be changed". Until this later spec appears though, I don't think we need to anticipate its requirements, and waste time here debating whether or not those unknown future requirements are a good thing or a bad thing. All we need to do now is avoid doing something truly silly like revising AH to have it include the flow label. The only plausible "mutable" argument I can see remaining for now is to have a case where the source host says "I don't care what is in this field, I am not setting it to anything". I haven't yet even seen an argument as to why that value has to be immutable (by definition it has no meaning to anyone). So, I'm still in favour of allowing that. But not so much as to object to a doc that doesn't include it - after all, no-one will ever care if that value is changed, so if anyone wants to do so, they can, regardless of what this new spec on the flow label claims. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:44:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3iQFh021175 for ; Wed, 13 Feb 2002 19:44:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3iQNC021174 for ipng-dist; Wed, 13 Feb 2002 19:44:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fn020775 for ; Wed, 13 Feb 2002 19:39:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12359 for ; Wed, 13 Feb 2002 19:18:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06998 for ; Wed, 13 Feb 2002 20:18:02 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: 8 Jan 2002 04:29:44 -0000 Message-ID: <20020108042944.15886.qmail@mailweb16.rediffmail.com> MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Query About IPv6 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g084VRNg014080 Status: RO X-Status: X-Keywords: X-UID: 251 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir/Madam, I have some queries regarding IPv6. I am still in the learning stage. So, my question may look very simple for you, but if you answer it, that will help me a lot. 1. What are the entries in the routing table under IPv6? 2. Can an Interface have more than one link local address? I'll be looking forward for the answers... regards, Ramakrishnan. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 19:42:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3gAFh021035 for ; Wed, 13 Feb 2002 19:42:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3g9QI021034 for ipng-dist; Wed, 13 Feb 2002 19:42:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HF020208 for ; Wed, 13 Feb 2002 19:31:13 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16723 for ; Wed, 13 Feb 2002 19:18:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28387 for ; Wed, 13 Feb 2002 19:18:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201231424.JAA09653@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-3gpp-recommend-00.txt Date: Wed, 23 Jan 2002 09:24:02 -0500 Status: RO X-Status: X-Keywords: X-UID: 889 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-00.txt Pages : 22 Date : 22-Jan-02 This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-3gpp-recommend-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020122153312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-3gpp-recommend-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153312.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:25:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4PqFh024693 for ; Wed, 13 Feb 2002 20:25:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4PpPi024692 for ipng-dist; Wed, 13 Feb 2002 20:25:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HH020208 for ; Wed, 13 Feb 2002 19:31:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16558 for ; Wed, 13 Feb 2002 19:18:38 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22108 for ; Wed, 13 Feb 2002 20:18:36 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201170954.g0H9sXQ59680@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Wed, 16 Jan 2002 11:02:56 PST. <4.3.2.7.2.20020116104249.024676b0@mailhost.iprg.nokia.com> Date: Thu, 17 Jan 2002 10:54:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 630 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >I have two concerns about this: > - the random order is not defined (this is a formal concern because > the intention is clear) I think most people will understand the intent of "random order". => as I've written this is a *formal* concern... (formal = on the form) > - we moved from an implementation hint to a SHOULD, this will make > old implementations not conformant and in some situations there > can be far better solutions. So I prefer to get a MAY (enough to > get this proposal implemented in the future by everybody without > harm) and an explicit reference to the default router preference > draft (first because I am in favor of this from the beginning, > i.e. since many years, second because this is the best reply to > the "special case" argument (not so special case because 100% of > the IPv6 networks I used have several routers with a better one)). I disagree. The intent of the document is to change the behavior from a hint to a common behavior. Hence the SHOULD. => if this is the intent the document is underspecified (i.e. it have to remember when the default router selection is done (this is at the beginning of 6.3.6)). There is too a real issue about the required minimal default router list length (two issues in fact: do we allow small implementations to use a short list (possibly shorter than the real number of default routers)? What is the reply to the bad guy who tries to give us 2^64 default routers?) Note there is something about this in 5.3 GC and Timeouts and 6.3.4 Processing rcvd RAs. Note that the current "hint" for round robin is less than perfect. => I agree but my concern is more about the requirement level. I think the current implementations are covered by the SHOULD. => they are not compliant with the SHOULD, not a real problem for round robin (as it can be looked at a bad random order) but implementations which keep the same router have a very different behavior (than the recommended one). If it was a MUST there might be a problem with current behavior. => I agree but a SHOULD in a draft standard (i.e. the intent) is really quite strong. In Salt Lake City where the issue of combining this with the default router preferences was discussed, the consensus was to keep this separate. => my concern is there are a lot of situations where some potential default routers are better than others. Without the default router preferences the only way to control the default router choice is to use zero router lifetimes. This is far too drastic and can't express any kind of nuance... So I'd really like to get preferences before or at the same time than random selection. The plan was to also add this behavior to the default router preferences draft for the case where there are multiple routers at the same preference. => we agree but there is clearly a problem in priorities. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:25:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4PlFh024676 for ; Wed, 13 Feb 2002 20:25:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4PlKF024674 for ipng-dist; Wed, 13 Feb 2002 20:25:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXHH019898 for ; Wed, 13 Feb 2002 19:25:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12194 for ; Wed, 13 Feb 2002 19:18:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22263 for ; Wed, 13 Feb 2002 20:18:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201221455.g0MEtQQ95681@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Comments to date on "IPv6 Host to Router Load Sharing" In-reply-to: Your message of Mon, 21 Jan 2002 17:22:08 PST. <4.3.2.7.2.20020121155821.02318e68@mailhost.iprg.nokia.com> Date: Tue, 22 Jan 2002 15:55:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 860 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1) Requirement level of SHOULD would make existing implementations non-compliant. 2) Relationship of this change to Neighbor Discovery and Default Router Preferences draft. Should they be combined? => what we asked is not really a combinaison, it was to get the default router preference not after the load sharing. The Default Router Preferences draft is an optional mechanism (see the draft). It may not always be used and/or implemented. => I'd like to see the same argument than in (1) applied to the default router preferences! Note this draft is not replacing the router preferences draft. Both are expected to go forward. This draft only changes the case when there is more than one default routers. It does not provide the optimum solution when there are multiple routers with different characteristics. That case is covered by the router preferences draft. => you know what we'd (people who did comments) like: to get both. 3) General statement load-distribution is not predictable behavior and is undesirable (e.g., using a single router until it fails is better). There is considerable current practice that disputes this. => there are situations where load sharing is better and others where it is a disaster. The only good solution is to get load-sharing with a way to control it, i.e. the default router preferences. I sent in July 1995 a mail about default router preferences, I never changed my opinion about this... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:25:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4PuFh024706 for ; Wed, 13 Feb 2002 20:25:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4Pu8Y024705 for ipng-dist; Wed, 13 Feb 2002 20:25:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gb020775 for ; Wed, 13 Feb 2002 19:39:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12297 for ; Wed, 13 Feb 2002 19:17:58 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06926 for ; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C32FE88.BAF513E2@hursley.ibm.com> Date: Wed, 02 Jan 2002 13:35:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112271745.fBRHj5C15277@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you analyse the text closely, "uniquely" is a noise word anyway- a label is unique within the scope of the things it labels in any case. We can certainly take it out. Brian Scott Bradner wrote: > > agree > > --- > >From owner-ipng@sunroof.eng.sun.com Thu Dec 27 11:11:09 2001 > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > X-Sender: mrw@mail.windriver.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 > Date: Thu, 27 Dec 2001 11:08:43 -0500 > To: Brian E Carpenter > From: Margaret Wasserman > Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Cc: ipng@sunroof.eng.sun.com > In-Reply-To: <3C2B41B4.2EF8D01B@hursley.ibm.com> > References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> > <878zbp8vh7.fsf@snark.piermont.com> > <3C2B2103.1B167487@hursley.ibm.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > > Actually, I would take out the word "uniquely". I am > not sure that we want to confine possible QoS solutions > to "uniquely" labeling anything. > > Margaret > > At 10:43 AM 12/27/01 , Brian E Carpenter wrote: > >Taking Scott's suggestion, here's another try: > > > >I'd like to propose the following as the > >complete and total replacement of Section 6 of RFC 2460. > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > > > This specification does not further define the meaning of the > > Flow Label. > > > > [and delete Appendix A, which is unhelpful.] > > > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:26:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4Q1Fh024715 for ; Wed, 13 Feb 2002 20:26:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4Q1fC024714 for ipng-dist; Wed, 13 Feb 2002 20:26:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Gx020208 for ; Wed, 13 Feb 2002 19:31:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16552 for ; Wed, 13 Feb 2002 19:18:39 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02630 for ; Wed, 13 Feb 2002 19:18:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1DC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Steven M. Bellovin'" , Brian E Carpenter Cc: Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: RE: Flow Label Date: Fri, 11 Jan 2002 16:14:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 385 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C3E9B37.486A9A8F@hursley.ibm.com>, Brian E > Carpenter writes: > >Indeed. All of this is the same for the DSCP actually, and the > >assumption is that operators will protect themselves with > >admission control. > > > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for > detailed discussion) > > > > Right. The question now is how to do that. I was about to agree > strongly with the "must send as zero if not a flow, routers > must not modify" > until I started thinking along these lines. What should a border > router do with a packet that doesn't meet its constraints? > I only see > three choices: reset the flow label to something locally > acceptable, > drop the packet, or tunnel. But dropping the packet means > that flow > labels can only be used for flows that stay within a > particular flow > label domain, and the tunneling path leads to madness. > (Well, perhaps > to MPLS, but I don't think we want to go down that rathole > now.) I'm > forced to conclude that we have two choices: either we > give up on flow > labels entirely, or we permit them to be modified en route. > => But as Robert Elz mentioned in a previous email, this is the same argument for IP addresses really. All we can do is mandate it in the standard, and if routers don't follow it, then they're breaking communication. I realise AH solves the problem for IP addresses, but how often is it used? or how often is it used specifically to protect addresses ? In addition AH is used for e2e integrity, not for intermediate routers. Doing something similar for intermediate routers is clearly...difficult. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:25:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4PmFh024678 for ; Wed, 13 Feb 2002 20:25:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3ms9u021280 for ipng-dist; Wed, 13 Feb 2002 19:48:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0G9020775 for ; Wed, 13 Feb 2002 19:39:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12380 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21829 for ; Wed, 13 Feb 2002 20:18:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: Brian E Carpenter cc: Margaret Wasserman , george+ipng@m5p.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <3C3586EE.9B8D002A@hursley.ibm.com> References: <3C3586EE.9B8D002A@hursley.ibm.com> <4.2.2.20020103144313.045caa60@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 20:17:56 +0700 Message-ID: <880.1010150276@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 122 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Jan 2002 11:41:50 +0100 From: Brian E Carpenter Message-ID: <3C3586EE.9B8D002A@hursley.ibm.com> | b) that the 3rd MUST should be SHOULD, i.e. immutability should | be default instead of mandatory. I'm not sure I believe the 100% immutable argument, but I certainly wouldn't deviate from it that far. That is, I'd keep it at MUST with just a very precise exception (which amounts to when the sender has specifically notified the router that the field may be changed). I'm pretty sure I'd never want to actually use the exception, except possibly to explicitly say "Do what you like" (or if you like, "this field isn't being used") - but I can't see what harm would be done by leaving that small exception available. In practical cases, explicitly notifying routers about specific flows where the label may be altered is most likely too difficult to ever happen, so this would probably just amount to allowing a single router to change the field from a sender's explicit "I don't care" into some other value. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:26:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4Q7Fh024723 for ; Wed, 13 Feb 2002 20:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4Q7Rp024722 for ipng-dist; Wed, 13 Feb 2002 20:26:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXI1019898 for ; Wed, 13 Feb 2002 19:26:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11861 for ; Wed, 13 Feb 2002 19:18:17 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02481 for ; Wed, 13 Feb 2002 19:18:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C3A017F.8FE859EB@txc.com> Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Subrata Goswami CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44A46AC3B890DC00D88A8F77" Status: RO X-Status: X-Keywords: X-UID: 238 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms44A46AC3B890DC00D88A8F77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The facts you mentioned (checksum and AH calculation) are wellknown, but a clear reminder is certainly useful for those who forgot, or ignored that. One of the comments pro "immutability" was that you cannot trust the flow label if it is not "immutable". But the no way to enforce or validate it -- possibly grotesque inconsistency -- is not why I am NOT for "immutability". The list of the flow setup and flow processing mechanisms is an open list: we do not know today all possible ways in which the flow label would be setup or used, in 10 or 20 years from now. Current or future flow setup and flow processing mechanisms, do now, or will, in the future, KNOW BEST the micro-details of the flow label usage. Therefore responsibility of the immutability/mutability of the flow label value should stay ALONE with those mechanisms. By leaving mutability alone, possible issues with checksum, and AH calculation can be really forgotten, or ignored. Alex Subrata Goswami wrote: > > The main point is, if I am a provider and I get a packet, how can > I be sure that some malicious entity in the middle has not modified > the flow label so that it can avail of better QoS ? Second your > assumption of not being able to handle flow label authentication may be > too conservative in light of Moore's law and developments in optics. > Third, not everybody works at the speed of 10GigE or OC-192 - there > are networks that works at lower speed where it is entirely possible > to do header processing in silicon even now. Fourth, you would still > need to change a Proposed Standard - so while we are at it why not > make it more complete. > > Also unless there is a mechanism to verify the immutation of the > flow label, just saying it is immutable is akin to making a law > and having no way to enforce it. > > So my vote ( I am not sure how much it is worth) would be > not to make it immutable unless we provide a way to verify the > immutation. > > Subrata > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter > Sent: Monday, January 07, 2002 2:15 AM > To: Subrata Goswami > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > We've already discussed the weak trust model aspect. Basically nobody will > be > doing cryptographic authentication of the flow label at line speed, and if > it isn't > done at line speed what's the point? > > Brian > > Subrata Goswami wrote: > > > > The wording for immutability aside, to really enforce immutability > > of the Flow Label , there must be a mechanism to verify that the > > Flow Label has not been changed. As can be seen from the ICV computation > > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence > there > > needs to be a new IPv6 header option for Flow Label immutability. > > > > 3.3.3.1.2 ICV Computation for IPv6 > > > > 3.3.3.1.2.1 Base Header Fields > > > > The IPv6 base header fields are classified as follows: > > > > Immutable > > Version > > Payload Length > > Next Header (This should be the value for AH.) > > Source Address > > Destination Address (without Routing Extension Header) > > > > Mutable but predictable > > Destination Address (with Routing Extension Header) > > > > Mutable (zeroed prior to ICV calculation) > > Class > > Flow Label > > Hop Limit > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Charles E. Perkins > > Sent: Friday, January 04, 2002 9:33 AM > > To: Brian E Carpenter > > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > > Subject: Re: Flow Label > > > > Hello Brian, > > > > Brian E Carpenter wrote: > > > > > > And, truth in advertising, we have heard two dissenting > > > views: > > > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > > the MAY clause below gets deleted > > > > I would say that MAY is a lot better. It suggests the truth, > > which is that people are going to try to figure out ways to > > use the flow label. It also motivates immutability. Otherwise, > > it is possible that some router vendors could simply zero out > > the field -- if it MUST BE ZERO, then zeroing it preserves > > immutability... We wouldn't want that. > > > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > > be default instead of mandatory. > > > > Any future technique for using the flow label would, if it violates > > immutability, be viewed as obsoleting this part of the specification > > anyway. So I would hope for a MUST here. Language suggesting that > > it is merely the default would allow for a tunable know in the user > > interface labeled thusly: > > "Flow Label treatment (default: do not change): " > > to be filled in by the system administrator. Possible other values > > selectable by the operator could be "randomize", "ones-complement", > > "store current time", ... (?). I don't know why anyone would do > > this, but I think we ought to be pretty clear about prohibiting it > > at least for now. > > > > Regards, > > Charlie P. > > > > > > > > Brian > > > > > > Margaret Wasserman wrote: > > > > > > > > Hi George, > > > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > > replace section 6 of RFC 2460 with the following text: > > > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > > source to label sets of packets. Nodes that do not support > > > > > the Flow Label field MUST set the field to zero when originating a > > > > > packet, and MUST ignore the field when receiving a packet. All > > routers > > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > > > This specification does not further define the meaning of the > > > > > Flow Label. > > > > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > > just publish a separate RFC that updates 2460. > > > > > > > > Margaret > > > > > > > > At 02:01 PM 1/3/02 , george+ipng@m5p.com wrote: > > > > >Just a quick question from an interested lurker: Are these hums of > > > > >acquiescence in response, specifically, to the idea that an > originating > > > > >node may set the flow label to any value, and that nodes forwarding > > > > >packets will leave that value alone? -- George Mitchell > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms44A46AC3B890DC00D88A8F77 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDcyMDEzNTNaMCMGCSqGSIb3DQEJ BDEWBBT7Oz+aWmvIB04YzhjpnnDOlB2W1DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgDG1R7GOU5lxk0UuRZ6QMFnfQoNbYSsqDhHi2lBrxKeie1so IvJIru8+NdrI0SOJusHEkXDhqgW/01/qUz8OCVwSpAYmOCnbvIMS9/WHgng/bYvEqJ5GRizg WTz0quh4d4U4oJP/8yWtDDmVvAMBmZc1R6ZXP7NA6dj/VJfLzr8t --------------ms44A46AC3B890DC00D88A8F77-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:26:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4QEFh024737 for ; Wed, 13 Feb 2002 20:26:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4QEvq024736 for ipng-dist; Wed, 13 Feb 2002 20:26:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gj020775 for ; Wed, 13 Feb 2002 19:39:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12422 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14712 for ; Wed, 13 Feb 2002 20:18:08 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201070903.g0793iQ13069@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 18:43:51 +0200. <00bf01c196d1$523f5ca0$8a1b6e0a@arenanet.fi> Date: Mon, 07 Jan 2002 10:03:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 205 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => this (to use AAA everywhere where there are mobile nodes) is the price > to pay to have an alternative to bidirectional tunnels with home agents, > i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling > (i.e. real world mobile IPv4). This seems like a bad design tradeoff to me. We already have a highly optimised mode of operation in MIPv6 (RO), => no, we have not this until the security problem is solved, i.e. it works but we may not deploy it... In fact (you sent this mail to the IPv6 WG mailing list only so I can say that without being nuke in some minutes) if Mobile IPv6 is expensive for CNs and only at the benefit of MNs it is in a real trouble. IMHO Routing Optimization has this problem, obviously not the bidirectional tunneling and not the triangular routing *if* the reply to the ingress filtering problem is not the burden of CNs. I disagree with most of the IESG security concerns with MIPv6 but the statement "This has negative implications for larger servers that process many 100s of thousands of connections at a time" is true, not only for AH/IPsec SAs. I think we must put the responsability of using HAOs to senders! and if you're not using it you are falling back to something less efficient. Your tradeoff improves the fallback solution a bit, but doesn't improve the optimised solution. And the cost is extreme: => I disagree, and the cost of RO is really extreme for CNs so if most of CNs just deny BUs we'll be happy to have a better fallback solution. we need a new global infrastructure (though I admit some of it will be built anyway), => first the implementation of smart ingress filtering and AAA is not even a SHOULD (RFC 2827 is a BCP), it seems you believe it is a MUST. Second the ingress filtering and HAOs is not a major security threat (like unprotected BUs in an open network is). To summary your argument would be valid if ingress filtering was mandatory and efficient, but today ingress filtering is not used by every ISPs and unfortunately to know where are the attackers is not enough to stop DDoS. MIPv6 deployment is delayed, => no, the only possible effect on deployment is another argument is favor of a better/real AAA. most if not all small sites and homes will not be able to benefit from RO, etc. => I agree that to ask for a better network access control in general stresses the trust/responsability problem. Regards Francis.Dupont@enst-bretagne.fr PS: don't forget that the BCE check solution has many drawbacks: - it doesn't work with not-MIPv6 uses of HAOs - it doesn't work without routing optimization - it makes CNs processing more complex/expensive - BCEs should be hard state. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:26:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4QPFh024772 for ; Wed, 13 Feb 2002 20:26:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4QPwg024770 for ipng-dist; Wed, 13 Feb 2002 20:26:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fv020775 for ; Wed, 13 Feb 2002 19:39:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12719 for ; Wed, 13 Feb 2002 19:19:02 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15090 for ; Wed, 13 Feb 2002 20:19:01 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201231733.g0NHX3r16487@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Irina Dayal" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Addr/Prefix clarification In-reply-to: Your message of "Wed, 23 Jan 2002 08:13:44 PST." <2B81403386729140A3A899A8B39B046405DE67@server2000.arneill-py.sacramento.ca.us> Date: Wed, 23 Jan 2002 12:33:03 -0500 Status: RO X-Status: X-Keywords: X-UID: 907 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have to disagree with Keith here. If a site wants to subnet, > they get a /48 and use the 16 SLA bits to subnet, that is what > they have been designed for. depends on what you mean by 'site', I suppose. Even if RFC 3177 is followed, I would not want the network to presume that a /64 net (such as might be assigned to a mobile network) should never be subnetted. there are good reasons to occasionally subnet a mobile network. and if we are not careful about how we allocate the top 64 bits we might need to allow subnetting of the lower 64 bits. In general, code and hardware should not presume much about the structure of addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:27:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4RMFh024933 for ; Wed, 13 Feb 2002 20:27:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4RLuw024931 for ipng-dist; Wed, 13 Feb 2002 20:27:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Gl020208 for ; Wed, 13 Feb 2002 19:30:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16576 for ; Wed, 13 Feb 2002 19:18:40 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07240 for ; Wed, 13 Feb 2002 20:18:36 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Mon, 7 Jan 2002 22:22:44 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: Michael Thomas , Francis Dupont , Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <3C39FFB7.7000303@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 239 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 7 Jan 2002, Pekka Nikander wrote: > Michael Thomas wrote: > > Also: if we have ingress filtering taken care of > > directly, is there any reason to preserve the HAO > > at all? I thought its entire raison d'etre was to > > provide a means of coexisting with ingress > > filtering -- which we've already proven is just > > shifting the problem around instead of providing > > something useful. > > Now THAT sounds like the most reasonable thing that > I have heard about ingress filtering for a long time! > > To me, it seems like combinding RR and CGA, the > ingress filtering router can fairly easily determine > that the MN really "owns" the home address, and > thereafter pass it. As an immediate reaction, the > only problem seems to be that CGA requires fairly > heavy CPU load. Could RR be enough in this case, > since the CoA and HoA are on the different sides > of the router? Moreover, ingress filtering is usually performed at more than one router. The network manager of the LAN might perform it. The network manager of the site should perform it. The network manager of the ISP should also perform it. Etc. Therefore, this "notification" or "ingress filtering registration" would have to operate a bit like path MTU discovery or a router alert option. Also, this would get more difficult in the case of multiple, changing paths (multihoming). Certainly an interesting idea, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:27:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4RjFh024972 for ; Wed, 13 Feb 2002 20:27:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4RiuQ024969 for ipng-dist; Wed, 13 Feb 2002 20:27:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HT020208 for ; Wed, 13 Feb 2002 19:31:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16203 for ; Wed, 13 Feb 2002 19:18:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14686 for ; Wed, 13 Feb 2002 20:18:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: "Dr. Subrata Goswami" To: Subject: RE: Flow Label Date: Tue, 8 Jan 2002 21:28:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3342.1010545708@brandenburg.cs.mu.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: X-Keywords: X-UID: 290 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here we go again, I guess first we need to make sure what immutability really is. The proper semantic of something immutable is that it can not be changed - as when you ship a CD that is only readable. With an IPv6 packet that is not possible unless every router vendor and IP stack vendor is some how forced to do that. Even the IP address fields are mutable as any intervening router can change (and they do in case of NAT). So the only way to enforce immutability is to add something like the AH so that anyone who is concerned with the Flow Label can be sure that no router in the middle has tempered it. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 7:08 PM To: Alex Conta Cc: Subrata Goswami; Brian E Carpenter; ipng@sunroof.eng.sun.com Subject: Re: Flow Label Date: Mon, 07 Jan 2002 15:13:51 -0500 From: Alex Conta Message-ID: <3C3A017F.8FE859EB@txc.com> | One of the comments pro "immutability" was that you cannot trust the | flow label if it is not "immutable". I didn't ever see that argument. What I saw was that you can't rely upon it if it isn't - but not from the point of view of the recipient, from the point of view of the sender. That is, if the value might be changed to any random thing, what's the point of setting it all, ever? It would just be meaningless bits (imagine a router forwarding a packet through an encrypting tunnel, and seeing some mutable bits - ones it is allowed to alter - and filling them with a random value in order to make cryptanalysis more difficult). | Current or future flow setup and flow processing mechanisms, do now, or | will, in the future, | KNOW BEST the micro-details of the flow label usage. Therefore | responsibility of the immutability/mutability of the flow label value | should stay ALONE with those mechanisms. I think in this case, you really favour making the field immutable, but unverified. If it were truly mutable, it would never be able to be used for any of those uses, as no-one could ever rely upon any value they set remaining intact to the point where it was supposed to be used (the "router" in my previous paragraph might be a link level bridge type object - even imagine a NIC that sees this mutable field and uses it to send to the destination a count of the number of times it deferred because of a busy link before sending the packet...) If some future spec wants to make the field mutable, then as long as we have not done anything silly (like modify the current AH rules) to prevent it, then that spec will be able to do that - and with a good chance of being able to rely upon the value only being changed as the future new spec actually says should happen. | By leaving mutability alone, possible issues with checksum, and AH | calculation can be really forgotten, or ignored. This amounts to "make it immutable, don't change AH, and explain in the doc that AH explicitly doesn't include the flow label, to leave open the possibility that some later spec might specify conditions under which the field can be changed". Until this later spec appears though, I don't think we need to anticipate its requirements, and waste time here debating whether or not those unknown future requirements are a good thing or a bad thing. All we need to do now is avoid doing something truly silly like revising AH to have it include the flow label. The only plausible "mutable" argument I can see remaining for now is to have a case where the source host says "I don't care what is in this field, I am not setting it to anything". I haven't yet even seen an argument as to why that value has to be immutable (by definition it has no meaning to anyone). So, I'm still in favour of allowing that. But not so much as to object to a doc that doesn't include it - after all, no-one will ever care if that value is changed, so if anyone wants to do so, they can, regardless of what this new spec on the flow label claims. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:28:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4STFh025046 for ; Wed, 13 Feb 2002 20:28:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4STmP025045 for ipng-dist; Wed, 13 Feb 2002 20:28:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5HL020208 for ; Wed, 13 Feb 2002 19:31:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16293 for ; Wed, 13 Feb 2002 19:18:15 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02479 for ; Wed, 13 Feb 2002 19:18:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C3E9963.A64C55CE@hursley.ibm.com> Date: Fri, 11 Jan 2002 08:50:59 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Update: Proposed update to RFC 2460 [was Re: Flow Label] References: <4.2.2.20020110123646.03743350@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 379 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Margaret. To give one example of where Jarno's addition can lead us into trouble, an SCTP flow may have several different addresses at different times; we could discuss for days whether Jarno's extra text is consistent with that case. But let's not do so; fewer words are better in this case. Brian Margaret Wasserman wrote: > > Hi Jarno, > > At 09:51 AM 1/10/02 , jarno.rajahalme@nokia.com wrote: > >I just reviewed the related threads on this list and the proposed text > >quoted below seems to have unanimous support (less ~2 persons) on the > >list. I support this text as well, but have a worry about it not stating > >in which context flow label, when set, is meaningful. > > I do not think that we should define this as part of the IPv6 > base specification. The semantics of the flow label (including how > it can (or can't) be used to identify a flow) should be specified > as part of any flow management mechanism that uses the IPv6 flow label > field. This may differ from one mechanism to another. > > I do not think that the base IPv6 specs should place any constraints > on how flow management mechanisms can use the flow label. > > NOTE: I realize that immutability is a constraint. I have > agreed to compromise on that one point. > > >The text below > >says that the label is used to "label sets of packets". In the SLC > >meeting I presented our proposal to consider the (Source Address, Flow > >Label, Destination Address) 3-tuple to classify the "set of packets". > > It would be okay with me to take out the words "sets of", if you > believe that this is confusing without further context. > > I do not think that we want to specify, as part of IPv6, that a 3-tuple > can be used to identify a flow. I have two reasons for this: > > - The 3-tuple that you describe is not sufficient to unambiguously > identify a flow without further specification of how/when > flow labels can be re-used by hosts. > - How to classify a flow shouldn't be part of the base IPv6 > specification -- it is specific to a flow management > mechanism. > > [...] > >Also, not stating > >how the "set" can be classified will not help HW-designers to do the > >right thing with their designs ASAP. > > Can you give examples of "right things" that could be done if we make > this change that could not be done if we don't make this change? > > >Text including the S+D addresses would be like (the second sentence is > >added, no other changes): > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to label sets of packets. A packet can be classified to a set > > with the source address, flow label, destination address triplet. > [...] > >So, for those who have hummed yes to the text below, how many of you > >would oppose modifying it to include mentioning the fields used for > >classification, and why? > > I strongly object to mentioning "the fields used for classification" as > part of the base IPv6 specs. I think that flow management mechanisms > and their semantics (including flow classification mechanism(s)) should > be specified in separate documents (and by separate WGs). > > Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:28:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4SZFh025057 for ; Wed, 13 Feb 2002 20:28:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4SZJJ025056 for ipng-dist; Wed, 13 Feb 2002 20:28:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXHp019898 for ; Wed, 13 Feb 2002 19:26:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11782 for ; Wed, 13 Feb 2002 19:18:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13495 for ; Wed, 13 Feb 2002 20:18:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: "Dr. Subrata Goswami" To: Subject: RE: Flow Label Date: Tue, 8 Jan 2002 23:12:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <874.1010558704@brandenburg.cs.mu.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: X-Keywords: X-UID: 293 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well I would not recommend settling something with screams. Making the Flow Label immutable would infact need more than screams. I can not see how by just saying something is immutable going to help. It would infact be the ground for more confusion, uncertainty, doubt and vendor specific interpretations. I would also recommend adopting the semantics of immutability from the AH RFC 2402 - I guess that is where the word immutable first appears. Also, as you know AH is completely broken by NAT. Why has NAT become popular ? I can only guess: a quick and dirty fix for IPv4 address scarcity; some firewall benefits. The -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 10:45 PM To: Dr. Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label Date: Tue, 8 Jan 2002 21:28:11 -0800 From: "Dr. Subrata Goswami" Message-ID: | Here we go again, I guess first we need to make sure | what immutability really is. The proper semantic of | something immutable is that it can not be changed - | as when you ship a CD that is only readable. Yes, though we perhaps aren't using it in quite that sense, more in the "must not be changed" rather than "can not be changed". | With an IPv6 | packet that is not possible unless every router vendor | and IP stack vendor is some how forced to do that. But that's certainly not true. We don't have to force them, we just need to tell them what is right. That's all the IETF ever really does. | Even the IP address fields are mutable as any intervening router | can change (and they do in case of NAT). Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields have just the properties that we are really aiming for here. That is, they aren't changed by random routers along the path - packets get delivered with the same addresses in them that they had when they left the source (or did, pre NAT). And that was achieved without AH existing yet to validate things - the routers simply didn't alter the fields. That's what is desirable here. But then, along came the need for NAT (as evil as it is, there must be a pretty strong case for it, given its widespread use). Implementing that meant that the address field, which previously had never been altered, now needed to be changed by routers. Had there been any enforcement of the immutability of the addresses, then there would have been no way to add NAT to the net (which might have been good, or bad, but for sure the net now would be nothing like it is if not for it). | So the only way | to enforce immutability is to add something like the AH so | that anyone who is concerned with the Flow Label can be | sure that no router in the middle has tempered it. If there was any reason to enforce it, that would be correct. But there isn't - so we don't need this. And if we did, then there'd be no possibility later to come up with some new use which requires the field to be mutable (and argue about it a lot in the IETF and perhaps eventually agree to it). At this stage in the evolution of the flow label, completely cutting off that possibility is unreasonable. In practice, if actual immutability is required by applications that use the flow label, then what will "enforce" the immutability is the screams of the users at the router vendors/operators if they start playing about with the data. Just as would happen if (aside from the explicitly configured NAT, and even that generates plenty of screaming) routers started randomly changing IP addresses. If there's never an application actually deployed that cares, then why would anyone else? In that case, if someone decides to alter the field, no-one would notice - and there's no reason to go and add a mechanism just to detect something that no-one cares about anyway. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:28:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4ShFh025072 for ; Wed, 13 Feb 2002 20:28:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4ShOx025071 for ipng-dist; Wed, 13 Feb 2002 20:28:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGr020453 for ; Wed, 13 Feb 2002 19:39:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04776 for ; Wed, 13 Feb 2002 19:18:34 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13740 for ; Wed, 13 Feb 2002 20:18:33 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f From: Robert Elz To: "Steven M. Bellovin" cc: Brian E Carpenter , Gerard.Gastaud@alcatel.fr, Subrata Goswami , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <20020111150246.D34077B4B@berkshire.research.att.com> References: <20020111150246.D34077B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 21:03:12 +0700 Message-ID: <5847.1011016992@brandenburg.cs.mu.OZ.AU> Status: RO X-Status: X-Keywords: X-UID: 464 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Jan 2002 10:02:46 -0500 From: "Steven M. Bellovin" Message-ID: <20020111150246.D34077B4B@berkshire.research.att.com> | But dropping the packet means that flow | labels can only be used for flows that stay within a particular flow | label domain, No, you have accepted one of Margaret's arguments, taken that to its logical conclusion, and reached absurdity, so obviously, something has to be wrong. But it isn't the immutability that's wrong, it is the assumption that different QoS mechanisms can redefine the flow label field in different incompatible ways. That simply cannot be allowed to happen, or any kind of usable QoS is even less likely to ever get deployed than the small chance there seems to be at the minute. There has to be (absolutely) one fixed consistent definition for the field, that all QoS mechanisms (now or in the future) can live with. If anyone needs some extra data that doesn't fit, they simply have to put that data elsewhere. If after doing that the flow label is useless to them, then they just don't use it. Exactly what the one fixed definition should be, I'll leave it to others to sort out, but there has to be exactly one - your analysis of what happens if things are allowed to become inconsistent shows that. Allowing routers to change the flow label to make it "legal" doesn't help - apart from simply making it say "unclassified" (which they could do just as easily by putting a magic value defined by them in the DCSP) from where would they get the information to install any other value. But if you can assume they can invent it from somewhere, then you need to work out how to handle the case where my packets flow through 3 independent ISPs, A B and C. I deal directly with A, so I can easily provide a flow label that suits A's requirements. If B doesn't like that, and changed it to something that fits B's requirements, what on earth happens when the packet reaches C? At that point, C has no idea what the flow label might mean - it could be something I put there, or it could be something local of B's. That's simply impossible to support. C has to know what the value represents (whether that then results in any special handling or not is up to whatever agreements exist among the various parties, and what they say - but regardless of that, if there's no way for C to interpret the request, then agreements would be useless). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:29:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4T1Fh025098 for ; Wed, 13 Feb 2002 20:29:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4T1Pv025097 for ipng-dist; Wed, 13 Feb 2002 20:29:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Gv020775 for ; Wed, 13 Feb 2002 19:39:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12499 for ; Wed, 13 Feb 2002 19:18:23 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13644 for ; Wed, 13 Feb 2002 20:18:22 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <3C3DA23E.CDD8C163@hursley.ibm.com> Date: Thu, 10 Jan 2002 15:16:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <874.1010558704@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 358 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre is correct IMHO, and we won't get any further by repeating this loop again. However there is one qualification on kre's final comment: > ...if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. The field could theoretically be abused as a signalling channel by malicious people - detecting this might be of value in some circumstances. Brian Robert Elz wrote: > > Date: Tue, 8 Jan 2002 21:28:11 -0800 > From: "Dr. Subrata Goswami" > Message-ID: > > | Here we go again, I guess first we need to make sure > | what immutability really is. The proper semantic of > | something immutable is that it can not be changed - > | as when you ship a CD that is only readable. > > Yes, though we perhaps aren't using it in quite that sense, more > in the "must not be changed" rather than "can not be changed". > > | With an IPv6 > | packet that is not possible unless every router vendor > | and IP stack vendor is some how forced to do that. > > But that's certainly not true. We don't have to force them, we just > need to tell them what is right. That's all the IETF ever really does. > > | Even the IP address fields are mutable as any intervening router > | can change (and they do in case of NAT). > > Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields > have just the properties that we are really aiming for here. That is, > they aren't changed by random routers along the path - packets get delivered > with the same addresses in them that they had when they left the source > (or did, pre NAT). And that was achieved without AH existing yet to > validate things - the routers simply didn't alter the fields. > > That's what is desirable here. > > But then, along came the need for NAT (as evil as it is, there must be > a pretty strong case for it, given its widespread use). Implementing that > meant that the address field, which previously had never been altered, > now needed to be changed by routers. Had there been any enforcement of > the immutability of the addresses, then there would have been no way to > add NAT to the net (which might have been good, or bad, but for sure the > net now would be nothing like it is if not for it). > > | So the only way > | to enforce immutability is to add something like the AH so > | that anyone who is concerned with the Flow Label can be > | sure that no router in the middle has tempered it. > > If there was any reason to enforce it, that would be correct. But there > isn't - so we don't need this. > > And if we did, then there'd be no possibility later to come up with some > new use which requires the field to be mutable (and argue about it a lot > in the IETF and perhaps eventually agree to it). At this stage in the > evolution of the flow label, completely cutting off that possibility is > unreasonable. > > In practice, if actual immutability is required by applications that use the > flow label, then what will "enforce" the immutability is the screams of the > users at the router vendors/operators if they start playing about with the > data. Just as would happen if (aside from the explicitly configured NAT, > and even that generates plenty of screaming) routers started randomly > changing IP addresses. > > If there's never an application actually deployed that cares, then why would > anyone else? In that case, if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. > > kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 20:29:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4TFFh025131 for ; Wed, 13 Feb 2002 20:29:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4TER4025128 for ipng-dist; Wed, 13 Feb 2002 20:29:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcH3020453 for ; Wed, 13 Feb 2002 19:39:24 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04697 for ; Wed, 13 Feb 2002 19:18:18 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28127 for ; Wed, 13 Feb 2002 19:18:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201080924.g089OOQ17946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 11:18:11 PST. <15417.62579.622952.287748@thomasm-u1.cisco.com> Date: Tue, 08 Jan 2002 10:24:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 255 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So here's a most-likely crazy idea: why can't we treat the ingress filtering router like a CN which must first be sent a BU which it verifies in whatever manner the CN would? This already has a requirement to not be bound to mythical PKI's, etc. Given FMIP, the access routers are probably going to end up having to process things like BU's anyway. => I suggest this in the smart anti-spoofing section (because this is what we used and the alternative is based on remote network access control or HA collaboration, i.e. something which needs a protocol) but this has many drawbacks: - if there is more than one path, some coordination is needed between routers on these paths - this works if HAOs are not used before BUs (with standard mobility, this is true because of home registrations but this is a restriction) - this puts constraints on how BUs/BAs are protected (no ESP hiding some parameters like the home address) - as a special case of the previous point, it is fine to be able to check the status in BAs of home registrations - this is complex and expensive (this is not bound to the number of MNs inside the site, this argument doesn't apply for the anti-spoofing because HAs are in general statically configured and in case of a flood of home registrations HAs should be overloaded before firewalls). So I believe this is a good complement but not a good candidate for smart ingress filtering. Also: if we have ingress filtering taken care of directly, is there any reason to preserve the HAO at all? I thought its entire raison d'etre was to provide a means of coexisting with ingress filtering -- which we've already proven is just shifting the problem around instead of providing something useful. => if I understand well your idea, you propose to disable traditional ingress filtering (so HAOs are no more useful). I believe this depends on the fraction of packets with HAOs, if it is high then I agree with you, if it is low then I believe ingress filtering remains useful... Regards Francis.Dupont@enst-bretagne.fr PS: I take advantage of this discussion to argue in favor of better network access control. It seems that today DDoS bad guys no more use random source address (i.e. ingress filtering is more efficient than one can believe), they try source addresses in the same prefix (change last bits in IPv4) in order to vary them (more harm for the target, counter measure more difficult). Of course this is easier for IPv6 but with a good network access control (even passive, i.e. the maximum number of boxes in a side is known) this can be detected and in many cases be fixed. (Thanks to Stanislav Shalunov who brought this point to my attention. Even if the purpose is to save the HAO by a reply on the paper to the traceback threat, it is fine to provide more applicable weapons against DDoSs) (Of course, a good network access control doesn't fit well with RFC 3041 but we already know there are some tradeoffs between privacy and access control :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:09:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E595Ib025535 for ; Wed, 13 Feb 2002 21:09:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E57jQR025528 for ipng-dist; Wed, 13 Feb 2002 21:07:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0I5020775; Wed, 13 Feb 2002 19:40:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12552; Wed, 13 Feb 2002 19:18:34 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28245; Wed, 13 Feb 2002 19:18:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C216@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] How to move forward in the HAO & ingress filter d iscussion Date: Thu, 17 Jan 2002 15:17:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Also, waiting for AAA solutions to be available > (specified, implemeted, > > and deployed) before MIPv6 can be used seems to be > counter to our desire > > to finish up MIPv6 soon. > > > > => I never proposed to wait for AAA solutions (as I > ask only for network > > access control, not everywhere but enough to make HAO > spoofing unattractive). > > Are you proposing to wait until network access control > is available? > (specified, implemented, and deployed) > > => we don't need to wait because mobile IPv6 is not yet > fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls > with IPv6 support > (or do you suggest to stop IPv6 until they are implemented > and deployed?) Status: RO X-Status: X-Keywords: X-UID: 646 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk => Ah, now I now what you meant before by not needing a solution. But this is really scarey, are you saying we wait until last call ( or worse, proposed standard) and then bring this up again ? Some people don't like that Francis :-) How can we be sure that the 'paper solution' you refer to will be deployed by the time MIPv6 is, if ever ... Hesham > > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In > parallel (because > even if the triangular routing is killed there are still > similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for > instance a > new RADIUS attribute for IPv6 inner source address > declaration). IMHO > this second part is mainly not technical (i.e. out of the > scope of IETF). > > Seems like this requires a two-phase approach: phase 1 > before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in > a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, > IPv6 ingress > filtering, IPv6 firewalls, ... > > What am I missing? > > => mobile IPv6 is not yet in last call, in fact we don't > know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. > But I agree we have to know where we are going or we could lose more > than our time in this kind of discussions (i.e. > implementers don't like > to follow random moving specs). > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:10:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5AmId025578 for ; Wed, 13 Feb 2002 21:10:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4lrhe025401 for ipng-dist; Wed, 13 Feb 2002 20:47:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Hb020775; Wed, 13 Feb 2002 19:40:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12282; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14605; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Was Node Mobility a Requirement for IPng? Date: Fri, 4 Jan 2002 14:26:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1955E.25F9D900" Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-Status: X-Keywords: X-UID: 151 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/plain; charset="iso-8859-1" Hello, Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. I'm just trying to understand the thinking of the past and how each might be reason to affect the other. Thanks, Glenn ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
Does anyone know if node mobility was a requirement for IPng during the debates among the proposals?
 
If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on.
 
I'm just trying to understand the thinking of the past and how each might be reason to affect the other.
 
Thanks,
 
Glenn
------_=_NextPart_001_01C1955E.25F9D900-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:14:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5EoIb025911 for ; Wed, 13 Feb 2002 21:14:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5EnjQ025910 for ipng-dist; Wed, 13 Feb 2002 21:14:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXJj019898; Wed, 13 Feb 2002 19:26:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11673; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02394; Wed, 13 Feb 2002 19:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Fri, 4 Jan 2002 09:15:55 -0800 (PST) To: Francis Dupont Cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> References: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-Status: X-Keywords: X-UID: 136 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. RPF checks "work" mainly because they are so painless for ISP's to implement. Anything beyond that is likely to be a complete non-starter. Mike Francis Dupont writes: > In your previous mail you wrote: > > However, I'm concerned about the "applied allover" > part. Specifically - while I'm very much fond of the AAA solutions - > I'm concerned whether we can expect all parts of the Internet to have > an infrastructure that really can figure out the home addresses. What > if there's a coin-operated (or Visa-) airport WLAN? > > => this is a problem of trust in the local/visited domain *and* in the > remote/home domain. In your example if I understand the issue is the lack > of trust in the local/visited domain, so one may reject traffic with > home address options from it. > > Finally, I seem to remember there was a discussion a long time ago whether > we could somehow provide automatic, mandatory, ingress filtering in IPv6. > > => my concern is that the "mandatory" term in a RFC is not enough to > enforce it in the real world. > > Currently, we are headed towards the same situation as in IPv4 > where ingress filtering is only partially applied, and we keep coming > up with "patch" solutions such as I-trace to help the situation. > > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). > > Interestingly, these solutions typically need changes to a large > fraction of the routers in the Internet which we already are doing > anyway to move to IPv6... > > => we can expect to avoid the same errors with IPv6. Unfortunately > ingress filtering (like network management) is something where IPv6 > is not yet at the same level than for IPv4 today. We hope this situation > will be improved very fast. > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:14:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5EgIb025897 for ; Wed, 13 Feb 2002 21:14:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5Eg2V025896 for ipng-dist; Wed, 13 Feb 2002 21:14:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXJJ019898; Wed, 13 Feb 2002 19:26:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11983; Wed, 13 Feb 2002 19:18:29 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07152; Wed, 13 Feb 2002 20:18:25 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 16:24:03 +0200. Date: Tue, 15 Jan 2002 16:04:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-Status: X-Keywords: X-UID: 563 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? => the same difference than when both ways are unoptimized or optimized. Difference in distance is the same, difference in byte overhead too. This is true for all points with one exception: protocol complexity because triangular routing has roughly the same complexity than bidirectional tunneling. Practice? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). => I can't see how TCP is involved. I believe your argument is different: if the traffic is very asymmetrical (more on one way than on the other), you prefer to have it on the optimized way... I am afraid the real argument against the triangular routing is this discussion itself because the main triangular routing advantage comes from the (future) fact that HAO is supported by every IPv6 nodes. With enough FUD this shall never become true and the advantage shall vanish... I'd like to get the opinion of IPv6 implementors (if they don't filter out this boring discussion) about HAO (for it, against it, will/won't implement it, will/won't enable it by default, etc). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:16:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5GNIb026158 for ; Wed, 13 Feb 2002 21:16:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5GNkd026152 for ipng-dist; Wed, 13 Feb 2002 21:16:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5FlJt025998 for ; Wed, 13 Feb 2002 21:16:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08676 for ; Wed, 13 Feb 2002 19:53:29 -0800 (PST) Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [210.163.32.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09604 for ; Wed, 13 Feb 2002 19:53:29 -0800 (PST) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail2.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id MAA05037; Thu, 14 Feb 2002 12:53:20 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id MAA05059; Thu, 14 Feb 2002 12:53:20 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id MAA05048; Thu, 14 Feb 2002 12:53:19 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id MAA20247; Thu, 14 Feb 2002 12:53:18 +0900 (JST) Message-ID: <00b701c1b50b$2b188720$30a0240a@local> From: "Yamasaki Toshi" To: "Lilian Fernandes" , Cc: References: Subject: Re: PPP and Global Addresses Date: Thu, 14 Feb 2002 12:52:07 +0900 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "PD (Automatic Prefix Delegation)" is one of the choices. draft-haberman-ipngwg-auto-prefix-01.txt http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-01. txt To solve all the configuration issues with DHCPv6 might be another good choice, but I guess PD be a minimum requirement for those who want an automatic prefix delegation mechanism for (for example) IPv6 access services, and DHCPv6 would be an option for those who want more. ---Toshi Yamasaki / NTT Communications > Hi, > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks > about the negotiation of the Interface-Identifier and specifies the > Interface-Identifier Configuration Option. In this case the upper 64 bits > are just fe80:: > > It does not mention if there is any standard way to configure a > global/site-local prefix on a point-to-point link i.e. are there > configuration options to let one side tell the other about a global > prefix? > > Or is it just left upto the users at both ends to decide on a prefix > somehow and then configure it on each end? > > I'm sorry if there is an RFC about this that I missed... > > Thanks, > Lilian > > _____________________________________________________________________ > > Lilian Fernandes > AIX TCP/IP Development - IBM Austin > Tel: 512-838-7966 Fax: 512-838-3509 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:46:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5krKL028020 for ; Wed, 13 Feb 2002 21:46:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5krb0028019 for ipng-dist; Wed, 13 Feb 2002 21:46:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5knKN028006 for ; Wed, 13 Feb 2002 21:46:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10008 for ; Wed, 13 Feb 2002 21:23:11 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27062 for ; Wed, 13 Feb 2002 21:21:21 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1E5KUc02134; Thu, 14 Feb 2002 12:20:50 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046406C322@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C322@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Feb 2002 12:20:30 +0700 Message-ID: <2132.1013664030@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 13 Feb 2002 08:51:23 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046406C322@server2000.arneill-py.sacramento.ca.us> | Absolutely. If you dial into your company, there is nothing that I | know of that says you must get a /64. The allocation of the SLA | bits is at the discretion of the company's network administrator, | and allocating a /60 to ... A while ago, you were insisting that everyone get a /48 ... (in this message you changed from absolute to "should", which is only a minor variation). What people get should depend upon their needs. It should be very easy to qualify for a /48, but if I don't need that much, and know don't need that much, why should anyone force me to take it? A /60 would do fine for me, that's about my need - a /128 would do just fine for my mother, that's her need (today anyway) (her system has no networking devices, other than a modem). | Poor choice of words. What is the word you would use to qualify | violating RFC2373? A broken standard. | Personally, I find the /64 way simpler. In the example above, it eats | 1/16th of the /48 and allows for 4,096 links. Organisations with more | than 4,096 links could use /51 or /50 and, if needed, request a /47 | or a /46. You missed the main point. You're still stuck in this mental model where there are providers, who have short prefix lengths, and other organisations which get longer ones (/48 .. perhaps /47 or /46 if they're very big). There is no such distinction, at some level, everyone is a provider - and attempting to force things into some model where they're not is simply absurd. I don't want to have to go running to APNIC (or ARIN or RIPE in other parts of the world) and try to justify getting a /35 or whatever their base (smallest) allocation is at the time, just because I want to connect a few friends and family to my house (thus becoming their ISP). Once again, all we need here is the most flexibility we can have, no built in assumptions about what is required to be a boundary (and to simply ignore any noise in any docs which claims there is such a thing). If we do that, and if we keep on having autoconf on the most common networks assuming it has a /64 to play in (leaving anyone wanting to use such a net requiring at least a prefix that long) and the world will sort itself out. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:53:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5rjKL028193 for ; Wed, 13 Feb 2002 21:53:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5riW5028191 for ipng-dist; Wed, 13 Feb 2002 21:53:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5rZKP028162 for ; Wed, 13 Feb 2002 21:53:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27505 for ; Wed, 13 Feb 2002 21:22:24 -0800 (PST) Received: from fep6.cogeco.net (smtp.cogeco.net [216.221.81.25]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27275 for ; Wed, 13 Feb 2002 21:22:24 -0800 (PST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep6.cogeco.net (Postfix) with ESMTP id A242F803 for ; Thu, 14 Feb 2002 00:22:22 -0500 (EST) Message-ID: <3C6B4ADD.971EA1F6@cgocable.net> Date: Thu, 14 Feb 2002 00:27:57 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: 114 messages!!!??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just went into my inbox and had to download 114 ipng messages (and only ipng messages) of various dates... has anybody else noticed this? I mean that is a rediculous amount of messages to go through. I wasn't thrilled. If I were on 56k i really wouldn't be happy having to hang my connection up for 20 minutes just to download email messages which should have ended up in my inbox ages ago but not all at once. Not my pop server doing this. :( I was just annoyed at the sheer volume of messages. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 21:53:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5riKL028190 for ; Wed, 13 Feb 2002 21:53:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5ri1u028189 for ipng-dist; Wed, 13 Feb 2002 21:53:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5rZKL028162 for ; Wed, 13 Feb 2002 21:53:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29870 for ; Wed, 13 Feb 2002 21:45:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05266 for ; Wed, 13 Feb 2002 21:45:11 -0800 (PST) Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Date: Wed, 13 Feb 2002 21:45:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DEBD@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Thread-Index: AcG1F2rHBcyjGUi9T5+wj8o0KBo4NAAAOWuQ From: "Michel Py" To: "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1E5rZKL028163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, >> Michel Py wrote: >> Absolutely. If you dial into your company, there is nothing that I >> know of that says you must get a /64. The allocation of the SLA >> bits is at the discretion of the company's network administrator, >> and allocating a /60 to ... > kre wrote: > A while ago, you were insisting that everyone get a /48 ... (in > this message you changed from absolute to "should", which is only > a minor variation). I have not changed my mind a bit: 1. Your university has a /48. 2. Your home gets a /48. 3. If your university provides you address space that you use in your home setup, that part is a university subnet. What I think the setup should be is: 1. get a /48 for your home. Subnet at will. 2a. If in your home setup, you need only one subnet with university addresses, then getting a /64 from the university to that one subnet is fine. Maybe don't need university addresses for the subnet you use for your microwave oven. 2b. If you have more than one subnet in your home that needs university addresses, these are multiple university subnets and then you should get a /60 (to stay on a nibble) from them. > Once again, all we need here is the most flexibility we can have, > no built in assumptions about what is required to be a boundary > (and to simply ignore any noise in any docs which claims there is > such a thing). I understand your point, and it is valid. Our opinions are based for part on our respectives experiences. Please allow me to share part of mine: - I can remember ten years ago when the company name associated with the word "network" was Novell, that I had to learn IP to tunnel IPX into it. For what I remember, IPX, with the MAC address being the host part and a fixed network/host boundary, was a lot simpler than IP. Same idea here with the fixed /64 boundary. - I teach IP (v4 and v6). You would be surprised to know how many students never grasp the VLSM concept. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 13 22:28:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S8KL028469 for ; Wed, 13 Feb 2002 22:28:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E6S8fv028468 for ipng-dist; Wed, 13 Feb 2002 22:28:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from opal.eng.sun.com (opal [129.146.86.88]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S3KL028461; Wed, 13 Feb 2002 22:28:03 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S6jK115404; Wed, 13 Feb 2002 22:28:06 -0800 (PST) Message-Id: <200202140628.g1E6S6jK115404@opal.eng.sun.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.3 To: ipng@sunroof.eng.sun.com, mobileip@sunroof.eng.sun.com Cc: postmaster@sunroof.eng.sun.com Subject: sorry about that... X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2002 22:28:06 -0800 From: John Beck Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks, Someone seems to have decided to re-send hundreds of old messages to your lists tonight. Fortunately, I was on duty and noticed a general problem, and one of your list mates (George Mitchell) was diligently paying attention and provided me with helpful details which greatly sped up my diagnosis. Anyway, the flood of the remaining 275 or so has been diverted and the offending site blocked, at least for now, though you may still get a trickle of messages that are still en route. I have also informed the postmaster of the problem site, as this sort of thing is usually a misconfiguration rather than someone being malicious. -- John Beck (postmaster@sunroof is one of my many hats) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 00:56:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E8ufKL029123 for ; Thu, 14 Feb 2002 00:56:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E8ufsf029122 for ipng-dist; Thu, 14 Feb 2002 00:56:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E8ucKL029115 for ; Thu, 14 Feb 2002 00:56:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14452 for ; Thu, 14 Feb 2002 00:56:40 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11855 for ; Thu, 14 Feb 2002 00:48:18 -0800 (PST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA26789; Thu, 14 Feb 2002 08:18:37 GMT Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA07083; Thu, 14 Feb 2002 08:18:37 GMT Date: Thu, 14 Feb 2002 08:18:37 +0000 (GMT) From: Tim Chown To: ryan elson cc: ipng@sunroof.eng.sun.com Subject: Re: 114 messages!!!??? In-Reply-To: <3C6B4ADD.971EA1F6@cgocable.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, I had this too. Interestingly the messages did not show up as new, so I'm wondering if my version of pine was misinterpreting some form of digest message that someone accidentally sent out. Tim On Thu, 14 Feb 2002, ryan elson wrote: > I just went into my inbox and had to download 114 ipng messages (and > only ipng messages) of various dates... > has anybody else noticed this? I mean that is a rediculous amount of > messages to go through. I wasn't thrilled. If I were on 56k i really > wouldn't be happy having to hang my connection up for 20 minutes just to > download email messages which should have ended up in my inbox ages ago > but not all at once. > Not my pop server doing this. > :( > I was just annoyed at the sheer volume of messages. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 01:41:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E9fXKL029270 for ; Thu, 14 Feb 2002 01:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E9fXfZ029269 for ipng-dist; Thu, 14 Feb 2002 01:41:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E9fUKL029262 for ; Thu, 14 Feb 2002 01:41:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24492 for ; Thu, 14 Feb 2002 01:41:33 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04347 for ; Thu, 14 Feb 2002 02:41:32 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA24596 for ipng@sunroof.eng.sun.com; Thu, 14 Feb 2002 10:41:30 +0100 (MET) Date: Thu, 14 Feb 2002 10:41:30 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: 114 messages!!!??? Message-ID: <20020214104130.A24476@theory.cs.uni-bonn.de> References: <3C6B4ADD.971EA1F6@cgocable.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tjc@ecs.soton.ac.uk on Thu, Feb 14, 2002 at 08:18:37AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2002 at 08:18:37AM +0000, Tim Chown wrote: >=20 > Yes, I had this too. Interestingly the messages did not show up as > new, so I'm wondering if my version of pine was misinterpreting some form > of digest message that someone accidentally sent out. I didn't see this. -is --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPGuGRjCn4om+4LhpAQFINwgAhIhSZwVGJjunibrM5PHTLfts6CkDDOTf tcxaxWKfai6cqEnWSo8iXe7PUKu72M+u3ahWcjqPjQfcXnbiX2mICmOMQIJQzDQk ZrmdaN3Diyuf0jSLGkm1uOtDs7AEGM9pL/pYspAGIPm3ZHMSr/QPL7VNTxO4UnQo S4snNEGWzXT5YQUpJW8iNvANe1Cs9nN16aIsXRUesVf5pSOkqyPVTYILp9pRfw5L sdoeM73YcPqw6DdiUblDmPWdf+zRz6/BWQOOOvHQjX4rv4LrkMs9g04kdJKcsEIW staIJw1h36sS6PpJv/1ZJRm3o4wGfM/b+f5PuSIFAKzkBmUfzNxJSw== =HOZ3 -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 01:50:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E9o3KL029315 for ; Thu, 14 Feb 2002 01:50:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E9o2Dv029314 for ipng-dist; Thu, 14 Feb 2002 01:50:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E9nxKL029307 for ; Thu, 14 Feb 2002 01:49:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27257 for ; Thu, 14 Feb 2002 01:50:02 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06789 for ; Thu, 14 Feb 2002 02:50:00 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1E9prW01131; Thu, 14 Feb 2002 16:51:54 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046405DEBD@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405DEBD@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Feb 2002 16:51:53 +0700 Message-ID: <1129.1013680313@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 13 Feb 2002 21:45:08 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405DEBD@server2000.arneill-py.sacramento.ca.us> | 1. Your university has a /48. | 2. Your home gets a /48. | 3. If your university provides you address space that you use in your | home setup, that part is a university subnet. The question is who otherwise provides the address space? And then what address space I provide to those who connect to my house, and what address space they provide others who connect to them. Please do remember that while multiple layers of connectivity today might be silly, as much of it is implemented out of ancient slow technology, there's no reason this has to continue into the future - we should certainly be planning for everyone to have high bandwidth low delay paths available. In that environment, there's a strong incentive for multiple orgs/people to group together, and between them buy a bigger pipe, as bandwidth costs are almost never linear. So, if ... | What I think the setup should be is: | 1. get a /48 for your home. Subnet at will. who issus that /48? The university's ISP isn't going to, they've never heard of me. APNIC? For every house in the AP region? And if they do, this will actually result in scalable routing? More likely, the university, that's where the connectivity goes - they're the ones who know who I am. And in that case, they're not going to be providing any /48's to me. If I'm going to get a /48 from somewhere, where would that be - without requiring me to abandon my nice employer sponsored connectivity (which I do use mostly for work related purposes) and go talk to some ISP with a /35 or something to carve up. | Our opinions are based for part on our respectives experiences. | Please allow me to share part of mine: I'm still waiting to hear about the global hierarchically routed Novell net which actually worked with its address plan, and how big that was. For sure, simple is better, but it has to actually work. | - I teach IP (v4 and v6). You would be surprised to know how many | students never grasp the VLSM concept. Many students never grasp almost any concept that one cares to name. Fortunately here, your average person doesn't have to grasp VLSM, all they need to deal with is "here is your prefix, it is N bits long, put those values in the config box where it asks". Even better if one day (ideally soon) they don't even need to see that, and just by connecting their box gets told the prefix to use. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 02:42:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EAgMKL029432 for ; Thu, 14 Feb 2002 02:42:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EAgM8E029431 for ipng-dist; Thu, 14 Feb 2002 02:42:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EAgIKL029424 for ; Thu, 14 Feb 2002 02:42:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05277 for ; Thu, 14 Feb 2002 02:42:18 -0800 (PST) Received: from lut.fi (stalk.cc.lut.fi [157.24.8.95]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02470 for ; Thu, 14 Feb 2002 03:42:17 -0700 (MST) Received: from [157.24.25.94] (HELO eilinel.pc.lut.fi) by lut.fi (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2470786; Thu, 14 Feb 2002 12:40:18 +0200 Received: from vnummela by eilinel.pc.lut.fi with local (Exim 3.32 #1 (Debian)) id 16bJIH-0004K6-00; Thu, 14 Feb 2002 12:39:13 +0200 To: Tim Chown Cc: ryan elson , ipng@sunroof.eng.sun.com Subject: Re: 114 messages!!!??? References: X-Face: "Df%ff/A[8\G2b3+^!5to-ud=~>-GK'R3S00Csb"a2XD}:"E8Y(ZS4|d#5d!]Y];+I+8(L;jzZM`?M5$QkA>C@"?Y5@&^):)@<_S|q_*v$dgZYh%-Kw<_g,9pmme24Zr|d;dvwK}}.1,K!uP)/mX\=1IhOn7Lvr=k$">br]sxlslZ8m%g,v'y/l`X5oObnS)C^q<:DTgvV^|&`QuPHF]YZJ8`q|z^mkeP,.['pv1eMZzflI4RE|1}t&{Pp'c-M;t~@T2L$$YtuFzM$`P~aN48_ohw:KbSYPvx]:IBS`\g Content-type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit From: Ville Nummela Date: 14 Feb 2002 12:39:13 +0200 In-Reply-To: (Tim Chown's message of "Thu, 14 Feb 2002 08:18:37 +0000 (GMT)") Message-ID: <87ofisgxf2.fsf@eilinel.pc.lut.fi> Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown writes: > Yes, I had this too. Interestingly the messages did not show up as > new, so I'm wondering if my version of pine was misinterpreting some form > of digest message that someone accidentally sent out. And, to be more interesting: My gnus suddenly decided that the ipng group is no longer uidvalid. -- | vnummela@lut.fi home: +358-40-5075560 | IRC naturae alienum est! Periculosum est! Delendum est! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 04:04:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EC4jKL029580 for ; Thu, 14 Feb 2002 04:04:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EC4i9v029579 for ipng-dist; Thu, 14 Feb 2002 04:04:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EC4fKL029572 for ; Thu, 14 Feb 2002 04:04:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03684 for ; Thu, 14 Feb 2002 04:04:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10849 for ; Thu, 14 Feb 2002 05:04:42 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15759; Thu, 14 Feb 2002 07:04:39 -0500 (EST) Message-Id: <200202141204.HAA15759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-ipv6-rh-hosts-00.txt Date: Thu, 14 Feb 2002 07:04:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Note about Routing Header Processing on IPv6 Hosts Author(s) : P. Savola Filename : draft-savola-ipv6-rh-hosts-00.txt Pages : 3 Date : 13-Feb-02 [IPV6] specifies routing header processing for nodes. The text is sufficiently ambiguous where the behaviour of hosts is concerned. This draft clarifies the issue by referring to IPv4 Host Requirements document and requiring hosts must not, by default, forward routing headers outside of the node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-hosts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-ipv6-rh-hosts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-ipv6-rh-hosts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020213142002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-ipv6-rh-hosts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-ipv6-rh-hosts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020213142002.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 05:24:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EDOiKL029678 for ; Thu, 14 Feb 2002 05:24:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EDOip3029677 for ipng-dist; Thu, 14 Feb 2002 05:24:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EDOeKL029670 for ; Thu, 14 Feb 2002 05:24:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16572 for ; Thu, 14 Feb 2002 05:24:43 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27134 for ; Thu, 14 Feb 2002 05:24:42 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EDOQk20768; Thu, 14 Feb 2002 14:24:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA18962; Thu, 14 Feb 2002 14:24:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EDOPg16279; Thu, 14 Feb 2002 14:24:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141324.g1EDOPg16279@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ole Troan cc: Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Thu, 14 Feb 2002 00:57:12 GMT. <7t5ofisswwn.fsf@mrwint.cisco.com> Date: Thu, 14 Feb 2002 14:24:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt > (search for Dialup Architecture, note this is my last attempt to find > an usefulness to DHCPv6 :-). we're just about to suggest a couple of new DHCPv6 options for this purpose. => you may but don't forget the vote was 0 (zero) in favour of DHCPv6 and at least Steve Deering is publicly strongly opposed to use DHCPv6 for router configuration. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 06:21:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEL2KL029817 for ; Thu, 14 Feb 2002 06:21:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EEL27G029816 for ipng-dist; Thu, 14 Feb 2002 06:21:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEKwKL029809; Thu, 14 Feb 2002 06:20:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14858; Thu, 14 Feb 2002 06:21:02 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14275; Thu, 14 Feb 2002 07:21:01 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EEKxk28131; Thu, 14 Feb 2002 15:20:59 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA20289; Thu, 14 Feb 2002 15:20:59 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EEKxg16494; Thu, 14 Feb 2002 15:20:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141420.g1EEKxg16494@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 03 Jan 2002 11:32:05 +0200. <3C342515.10904@nomadiclab.com> Date: Thu, 14 Feb 2002 15:20:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished... => note the draft was finished and published. The draft is quite nice, thanks for writing it. => thanks for reading it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. => I assume you use AAA in its traditional meaning, i.e. network access control with something like RADIUS. Please don't make the confusion between network addresse control and full AAA with infrastructure, etc. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. => there are other options (look at the mobile-ip list) but it seems the two detailed proposals are ingress filtering using some kind/level of network access control and binding cache entry check. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) => I agree the zero-configuration is very fine and I don't believe into DHCPv6, i.e. something which tries to impose its idea of your address to you. But I make a distinction between to allow hosts to be plugged in and to allow hosts to freely access to the Internet. The device which provides the step between is the network access control. I don't want to enter into details about how to do it, the important notion is the trust/responsability, i.e. if you give some access to a node and something is going wrong, you accept to take the responsability to take care of the problem. IMHO this is more important than ingress filtering itself: without trust/responsability, the bad guy has no need to do source address spoofing. So, as I am perhaps (:-) in the people who disagree with you, what you propose if you get the role of a public access WLAN manager? Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. => this proves ingress filtering reachs its limits when an action is required... When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. => I agree: network access control doesn't imply good administration but usually it is simply part of a at least minimal administration (always better than nothing). For instance location of compromised hosts can be possible. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. => the issue is in the target: you'd like to secure the Internet, this is an admirable idea but, for some reasons you have just explained, not really feasible. My purpose is to get back to the previous situation, i.e. current IPv4 ingress filtering, so I prefer to stress the trust/ responsability stuff (what I called the "responsible usage of the network") because in fact the places where advanced ingress filtering won't work are the places where ingress filtering itself won't work. I have a lot of other arguments but they are already in the zillion of previous messages about the HAO security... BTW the design team proposed a recommendation based on the FUD against mobile IPv6 and selected the BCE check solution. I am very pessimist about the future of mobile IPv6 because the improvements over mobile IPv4 fully rely on the routing optimization: as someone explained, there are only two kinds of common correspondent nodes: web servers, but to deal with routing optimization with its security, hard state binding cache, etc, is too expensive so shan't be done, and mobile terminals (handsets, PDAs, (robust) laptops), the problem is the design team didn't consider this special case (aka mobile to mobile)... We are trying to save something but most of the marvellous promises of mobile IPv6 can already be considered as hype. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 07:10:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFAMKL000138 for ; Thu, 14 Feb 2002 07:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EFAMKu000137 for ipng-dist; Thu, 14 Feb 2002 07:10:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFAIKL000123; Thu, 14 Feb 2002 07:10:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25151; Thu, 14 Feb 2002 07:10:20 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16085; Thu, 14 Feb 2002 08:10:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EFADk02772; Thu, 14 Feb 2002 16:10:13 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA21495; Thu, 14 Feb 2002 16:10:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EFADg17838; Thu, 14 Feb 2002 16:10:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141510.g1EFADg17838@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: John Beck cc: ipng@sunroof.eng.sun.com, mobileip@sunroof.eng.sun.com Subject: Re: sorry about that... In-reply-to: Your message of Wed, 13 Feb 2002 22:28:06 PST. <200202140628.g1E6S6jK115404@opal.eng.sun.com> Date: Thu, 14 Feb 2002 16:10:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your fix! Francis.Dupont@enst-bretagne.fr PS: I apologize because I've answered the first message and contributed to the load (we should be surprised to get such a large number of messages :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 07:31:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFV1KL000177 for ; Thu, 14 Feb 2002 07:31:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EFV1Pf000176 for ipng-dist; Thu, 14 Feb 2002 07:31:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFUuKL000168; Thu, 14 Feb 2002 07:30:56 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EFUoM07516; Thu, 14 Feb 2002 16:30:50 +0100 (MET) Date: Thu, 14 Feb 2002 16:26:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202141420.g1EEKxg16494@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am very pessimist about the future of mobile IPv6 > because the improvements over mobile IPv4 fully rely on the routing > optimization: as someone explained, there are only two kinds of common > correspondent nodes: web servers, but to deal with routing optimization > with its security, hard state binding cache, etc, is too expensive so > shan't be done, and mobile terminals (handsets, PDAs, (robust) laptops), > the problem is the design team didn't consider this special case (aka > mobile to mobile)... We are trying to save something but most of the > marvellous promises of mobile IPv6 can already be considered as hype. Francis, I don't share you pessimism. I think the claim that there are only two types of CNs that matter for mobile IPv6 (Web servers and mobile terminals) is a bit odd. That is similar to saying that since most of the traffic on the internet is http why don't be build an http network instead of an IP network? The point is that the value of the Internet comes from service/application independence - people can build new services and applications and have them run on the Internet today - no need to upgrade things in the middle to deploy new things. So building a http + voip network is the wrong thing to do and the above statement sounds like it would be the right approach which is why I disagree with it rather strongly. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 07:47:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFlFKL000335 for ; Thu, 14 Feb 2002 07:47:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EFlFUb000334 for ipng-dist; Thu, 14 Feb 2002 07:47:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFlCKL000327 for ; Thu, 14 Feb 2002 07:47:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04671 for ; Thu, 14 Feb 2002 07:47:14 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07398 for ; Thu, 14 Feb 2002 08:47:14 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1EFlDh07104; Thu, 14 Feb 2002 07:47:13 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACP79913; Thu, 14 Feb 2002 07:47:02 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20020212061255.27232.qmail@mailweb15.rediffmail.com> References: <20020212061255.27232.qmail@mailweb15.rediffmail.com> Date: Thu, 14 Feb 2002 07:47:11 -0800 To: "Ramakrishnan" From: Steve Deering Subject: Re: Query regarding loopback interface Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:12 AM +0000 2/12/02, Ramakrishnan wrote: >Q) if we have any virtual link (ex. loopback) it will have a loopback address. Other than that, should we need to have any link local address for that interface. ? Ramakrishnan, The loopback link does not require a link-local address. If you have virtual links that can have more than one node attached (e.g., some people refer to an IP tunnel as a virtual link), those links will need link-local addresses for the (virtually) attached nodes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 08:05:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EG5gKL000430 for ; Thu, 14 Feb 2002 08:05:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EG5gx9000429 for ipng-dist; Thu, 14 Feb 2002 08:05:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EG5dKL000422 for ; Thu, 14 Feb 2002 08:05:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09253 for ; Thu, 14 Feb 2002 08:05:41 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17296 for ; Thu, 14 Feb 2002 09:05:40 -0700 (MST) Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Date: Thu, 14 Feb 2002 08:05:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046405DEBE@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Thread-Index: AcG1PQZsbMgz+0YtTOC5TOm8Dhs+bQAMlp1A From: "Michel Py" To: "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1EG5dKL000423 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > The question is who otherwise provides the address space? And then > what address space I provide to those who connect to my house, and > what address space they provide others who connect to them. Agree. > Please do remember that while multiple layers of connectivity today > might be silly, as much of it is implemented out of ancient slow > technology, there's no reason this has to continue into the future > - we should certainly be planning for everyone to have high bandwidth > low delay paths available. In that environment, there's a strong > incentive for multiple orgs/people to group together, and between > them buy a bigger pipe, as bandwidth costs are almost never linear. Agree again. >> What I think the setup should be is: >> 1. get a /48 for your home. Subnet at will. > who issus that /48? The university's ISP isn't going to, they've > never heard of me. This is wrong. If the university is in the ISP business, they should get a /35 or a /29. > And in that case, they're not going to be providing any /48's to me. You keep trying to break RFC 2373 to solve problems that have been caused by people that have not done things right to begin with. It is ok for a university to get a /48 for staff/internal stuff. It is not ok to try to run an ISP with a /48. Period. Trying to subnet a /64 because your ISP is trying to run their business out of a /48 is not a realistic solution. Talk to your ISP and tell them to do things right and get a /35 or a /29. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 08:05:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EG5wKL000441 for ; Thu, 14 Feb 2002 08:05:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EG5w34000440 for ipng-dist; Thu, 14 Feb 2002 08:05:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EG5qKL000433 for ; Thu, 14 Feb 2002 08:05:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EG5pM12118; Thu, 14 Feb 2002 17:05:51 +0100 (MET) Date: Thu, 14 Feb 2002 17:01:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 114 messages!!!??? To: Tim Chown Cc: ryan elson , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes, I had this too. Interestingly the messages did not show up as > new, so I'm wondering if my version of pine was misinterpreting some form > of digest message that someone accidentally sent out. Quite odd. My imap client (roam) also had all the messages marked as already read in my inbox. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 08:48:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGmhKL000717 for ; Thu, 14 Feb 2002 08:48:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EGmhWT000716 for ipng-dist; Thu, 14 Feb 2002 08:48:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGmeKL000709; Thu, 14 Feb 2002 08:48:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16453; Thu, 14 Feb 2002 08:48:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19605; Thu, 14 Feb 2002 09:48:41 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EGmdk17150; Thu, 14 Feb 2002 17:48:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA24312; Thu, 14 Feb 2002 17:48:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EGmdg18727; Thu, 14 Feb 2002 17:48:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141648.g1EGmdg18727@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 14 Feb 2002 16:26:34 +0100. Date: Thu, 14 Feb 2002 17:48:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I don't share you pessimism. => I'd prefer to be wrong... I think the claim that there are only two types of CNs that matter for mobile IPv6 (Web servers and mobile terminals) is a bit odd. => this is not my claim but this is clearly the vision of the Internet by many players in Europe (worse in France where the Internet is the super Minitel, brrr...) That is similar to saying that since most of the traffic on the internet is http why don't be build an http network instead of an IP network? => Brian Carpenter argues this can become the future of the Internet. Of course we don't want that, but remember I've begun by "I am pessimistic" and there is somthing named SOAP... The point is that the value of the Internet comes from service/application independence - people can build new services and applications and have them run on the Internet today - no need to upgrade things in the middle to deploy new things. => you don't need to convince me and I'm afraid the folks we should convince don't read these lists. So building a http + voip network is the wrong thing to do and => if you replace http by WAP (not an improvement) this is exactly what they are trying to do (I don't add a smile because this is *not* funny). the above statement sounds like it would be the right approach which is why I disagree with it rather strongly. => there is what we'd like and there is what it is (look better in French)... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 10:08:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI8eKL002106 for ; Thu, 14 Feb 2002 10:08:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EI8dqs002105 for ipng-dist; Thu, 14 Feb 2002 10:08:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI8YKL002098 for ; Thu, 14 Feb 2002 10:08:34 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EI8WM25530; Thu, 14 Feb 2002 19:08:32 +0100 (MET) Date: Thu, 14 Feb 2002 19:04:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" To: Francis Dupont Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202132005.g1DK5dg11474@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => please keep the current text, we'll see for something else/better > for the next revision (the advanced API doesn't need to be perfect, > it needs to be published!) Agreed. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 10:28:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EISOKL002150 for ; Thu, 14 Feb 2002 10:28:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EISOmP002149 for ipng-dist; Thu, 14 Feb 2002 10:28:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EISKKL002142 for ; Thu, 14 Feb 2002 10:28:20 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28963 for ; Thu, 14 Feb 2002 10:28:22 -0800 (PST) Received: from vmmr2.verisignmail.com (vmmr2.verisignmail.com [216.168.230.139]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16858 for ; Thu, 14 Feb 2002 10:28:21 -0800 (PST) Received: from vmms2.verisignmail.com (vmms2.verisignmail.com [10.166.0.140]) by vmmr2.verisignmail.com (Mirapoint) with ESMTP id ACD22035; Thu, 14 Feb 2002 13:28:16 -0500 (EST) Received: from emergencecommunications.net (12-236-148-136.client.attbi.com [12.236.148.136]) by vmms2.verisignmail.com (Mirapoint) with ESMTP id AHN67056; Thu, 14 Feb 2002 13:28:14 -0500 (EST) Message-ID: <3C6C01BF.8010103@emergencecommunications.net> Date: Thu, 14 Feb 2002 10:28:15 -0800 From: Jim Stephenson-Dunn User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark CC: Tim Chown , ryan elson , ipng@sunroof.eng.sun.com Subject: Re: 114 messages!!!??? References: Content-Type: multipart/alternative; boundary="------------070207040809020706040403" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------070207040809020706040403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I also saw this, I am using Netscape mail. Many of the messages were from the beginning of the year, Netscape had flagged them as unread though. I saw nothing unusual on our mail server. Jim Erik Nordmark wrote: >>Yes, I had this too. Interestingly the messages did not show up as >>new, so I'm wondering if my version of pine was misinterpreting some form >>of digest message that someone accidentally sent out. >> > >Quite odd. >My imap client (roam) also had all the messages marked as already read >in my inbox. > > Erik > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --------------070207040809020706040403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I also saw this, I am using Netscape mail. Many of the messages were from the beginning of the year, Netscape had flagged them as unread though. I saw nothing unusual on our mail server.

Jim

Erik Nordmark wrote:
Yes, I had this too.   Interestingly the messages did not show up as
new, so I'm wondering if my version of pine was misinterpreting some form
of digest message that someone accidentally sent out.

Quite odd.
My imap client (roam) also had all the messages marked as already read
in my inbox.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------
Jim Stephenson-Dunn

--------------070207040809020706040403-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 10:56:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EIu0KL002299 for ; Thu, 14 Feb 2002 10:56:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EIu0l9002298 for ipng-dist; Thu, 14 Feb 2002 10:56:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EItuKL002291 for ; Thu, 14 Feb 2002 10:55:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25313 for ; Thu, 14 Feb 2002 10:55:58 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28023 for ; Thu, 14 Feb 2002 11:55:57 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA16074; Thu, 14 Feb 2002 10:56:29 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA29328; Thu, 14 Feb 2002 10:56:30 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA02715; Thu, 14 Feb 2002 10:57:45 -0800 (PST) Date: Thu, 14 Feb 2002 10:57:45 -0800 (PST) From: Tim Hartrick Message-Id: <200202141857.KAA02715@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > I agree. If it is really easy to deal with the send side as you said, > it would be the best candidate (so I'd like to know the details). > I had missed the change in receive side semantics. More badness. Why can't the order of the setsockopt calls establish the order of the routing header and the destination options? I don't see why it isn't that simple except in the case where ancillary data and sticky options are intermingled. This is another reason why it was better to allow ancillary data to override ALL sticky options rather than just like sticky options. This change has substantially complicated the implementation for little benefit. Oh well. Just put this mess to bed. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 11:34:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJYVKL002937 for ; Thu, 14 Feb 2002 11:34:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJYFI2002936 for ipng-dist; Thu, 14 Feb 2002 11:34:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJYCKL002927 for ; Thu, 14 Feb 2002 11:34:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04718 for ; Thu, 14 Feb 2002 11:34:14 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24264 for ; Thu, 14 Feb 2002 11:34:13 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA19730; Thu, 14 Feb 2002 19:34:02 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Francis Dupont Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses References: <200202141324.g1EDOPg16279@givry.rennes.enst-bretagne.fr> From: Ole Troan Date: Thu, 14 Feb 2002 19:34:02 +0000 In-Reply-To: <200202141324.g1EDOPg16279@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Thu, 14 Feb 2002 14:24:25 +0100") Message-ID: <7t5vgczhn85.fsf@mrwint.cisco.com> Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > > http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt > > (search for Dialup Architecture, note this is my last attempt to find > > an usefulness to DHCPv6 :-). > > we're just about to suggest a couple of new DHCPv6 options for this > purpose. > > => you may but don't forget the vote was 0 (zero) in favour of DHCPv6 > and at least Steve Deering is publicly strongly opposed to use DHCPv6 > for router configuration. I'll let Steve speak for himself. it turns out that router to router prefix delegation has a number of conceptual similarities with statefull address assignment. instead of making a new protocol evolve into DHCP under a different name, I suggest we reconsider the use of DHCP. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 14:54:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EMskKL004247 for ; Thu, 14 Feb 2002 14:54:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EMskHc004246 for ipng-dist; Thu, 14 Feb 2002 14:54:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EMshKL004239 for ; Thu, 14 Feb 2002 14:54:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14532 for ; Thu, 14 Feb 2002 14:54:46 -0800 (PST) Received: from gate.alliedtelesyn.co.nz (gate.alliedtelesyn.co.nz [202.49.72.33]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA18691 for ; Thu, 14 Feb 2002 14:54:43 -0800 (PST) Received: (qmail 11296 invoked from network); 14 Feb 2002 21:59:32 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 14 Feb 2002 21:59:32 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 15 Feb 02 11:53:36 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 15 Feb 02 11:53:32 +1300 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: ipng@sunroof.eng.sun.com Date: Fri, 15 Feb 2002 11:53:24 +1300 (NZDST) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: PPP and VLAN link-local addresses Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3C6CF67F.30.4C1A3CAD@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I was wondering if this has been mentioned before. Will there be adverse effects( is this allowed in the first place?) from modifying the link-local address from 16 16 16 16 16 16 16 16 bits fe80 0 0 0 <-------eui-64 id---> to 16 16 16 16 16 16 16 16 bits fe80 0 <--vlan--> <-------eui-64 id---> or ppp ID so as to have the last 32 bits of the hgiher 64 bits of the link-local address to represent the interface ID or the VLAN or PPP ID. Or is this 32- bits reserved for something else? Also, I take it that the global bit in the eui-64 identifier will still be set if the above format is allowed? Regards, Sean ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 16:32:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F0WDKL005032 for ; Thu, 14 Feb 2002 16:32:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F0WCkK005031 for ipng-dist; Thu, 14 Feb 2002 16:32:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F0W9KL005024 for ; Thu, 14 Feb 2002 16:32:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07439 for ; Thu, 14 Feb 2002 16:32:12 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06315 for ; Thu, 14 Feb 2002 17:32:11 -0700 (MST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id JAA22347 for ; Fri, 15 Feb 2002 09:32:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g1F0WA403530 for ; Fri, 15 Feb 2002 09:32:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA03529 ; Fri, 15 Feb 2002 09:32:10 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id JAA11339; Fri, 15 Feb 2002 09:32:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id JAA05817; Fri, 15 Feb 2002 09:32:09 +0900 (JST) Received: from localhost ([172.30.24.108]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0GRJ00CUZTHHAJ@tsbpo1.po.toshiba.co.jp> for ipng@sunroof.eng.sun.com; Fri, 15 Feb 2002 09:32:08 +0900 (JST) Date: Thu, 14 Feb 2002 19:32:03 -0500 (EST) From: NAKAJIMA Nobuyasu Subject: sending packets before completing DAD To: ipng@sunroof.eng.sun.com Message-id: <20020214.193203.91280686.nobuyasu.nakajima@toshiba.co.jp> MIME-version: 1.0 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I am a newbie to this list. I apologize if my question is frequently asked. RFC2462 says that the node only accepts particular Neighbor Solicitation and Neighbor Advertisement messages during DAD process, and other packets should be discarded. So the node behavior of the packet reception part in the process of DAD is clear to me. My question is whether the node in the process of DAD can send the packets other than Neighbor Solicitations for the purpose of DAD. RFC2462 says that the tentative address cannot be assigned to the interface. So I think the node cannot send packets before completing DAD. Is this interpretation correct? I would appreciate if somebody would answer to this question. Thanks ----- Nobuyasu Nakajima Toshiba America Research, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 20:57:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F4v9KL006085 for ; Thu, 14 Feb 2002 20:57:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F4v9p7006084 for ipng-dist; Thu, 14 Feb 2002 20:57:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F4v5KL006077 for ; Thu, 14 Feb 2002 20:57:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16554 for ; Thu, 14 Feb 2002 20:57:10 -0800 (PST) Received: from mailweb11.rediffmail.com ([203.199.83.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA25224 for ; Thu, 14 Feb 2002 21:57:08 -0700 (MST) Received: (qmail 31841 invoked by uid 510); 15 Feb 2002 04:56:32 -0000 Date: 15 Feb 2002 04:56:32 -0000 Message-ID: <20020215045632.31840.qmail@mailweb11.rediffmail.com> Received: from unknown (203.196.145.150) by rediffmail.com via HTTP; 15 Feb 2002 04:56:32 -0000 MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: "NAKAJIMA Nobuyasu" Cc: ipng@sunroof.eng.sun.com Subject: Re: sending packets before completing DAD Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1F4v6KL006078 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, i am also on the learning stage of IPV6 and as per RFC 2461 & 2462 i think, to speedup the autoconfiguration, router solicitation message (with source address Unspecified) can be sent while DAD is in progress. Regards, Ramakrishnan On Fri, 15 Feb 2002 NAKAJIMA Nobuyasu wrote : > Hello, > > I am a newbie to this list. I apologize if my question > is frequently > asked. > > RFC2462 says that the node only accepts particular > Neighbor > Solicitation and Neighbor Advertisement messages during > DAD process, > and other packets should be discarded. So the node > behavior of the > packet reception part in the process of DAD is clear to > me. > > My question is whether the node in the process of DAD > can send the > packets other than Neighbor Solicitations for the > purpose of DAD. > > RFC2462 says that the tentative address cannot be > assigned to the > interface. So I think the node cannot send packets > before completing > DAD. Is this interpretation correct? > > I would appreciate if somebody would answer to this > question. > > Thanks > ----- > Nobuyasu Nakajima > Toshiba America Research, Inc. > --------------------------------------------------------- > ------------ > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > --------------------------------------------------------- > ------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 14 21:17:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F5HMKL006139 for ; Thu, 14 Feb 2002 21:17:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F5HMCX006138 for ipng-dist; Thu, 14 Feb 2002 21:17:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F5HJKL006131 for ; Thu, 14 Feb 2002 21:17:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05470 for ; Thu, 14 Feb 2002 21:17:23 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27452 for ; Thu, 14 Feb 2002 22:16:48 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1F5E1I01751; Fri, 15 Feb 2002 12:14:01 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) In-Reply-To: <2B81403386729140A3A899A8B39B046405DEBE@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405DEBE@server2000.arneill-py.sacramento.ca.us> Date: Fri, 15 Feb 2002 12:14:01 +0700 Message-ID: <1749.1013750041@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 14 Feb 2002 08:05:39 -0800 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405DEBE@server2000.arneill-py.sacramento.ca.us> | This is wrong. If the university is in the ISP business, they should | get a /35 or a /29. They're not. | You keep trying to break RFC 2373 to solve problems that have been | caused by people that have not done things right to begin with. It is this notion that there is a "right" that I am opposed to. There are lots of acceptable ways to operate, and all of them should be permitted. Ans it wasn't I who "broke" 2373, it is broken as it is written. | It is not ok to try to run an ISP with a /48. Period. Buit there (aside from marketing speak) is no distinction between something that is an ISP and something that is not. That's the point I am trying to make. Anyone and everyone can connect others. Or they should be able to. We shouldn't be even considering setting up an environment where connections are only permitetd to be made to the priveleged few who have /35's - or the answer will have to be that everyone will simply go request a /35 instead of a /48. Stop trying to label people/organisations into categories. Address space blocks outght to be allocated based upon the number of sub-addresses that need to be allocated, not upon some label. If I have just a couple to allocate, and I am prepared to live with the consequences, then subnetting a /64 should work just fine. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 01:06:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F96EKL006798 for ; Fri, 15 Feb 2002 01:06:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F96Ejn006797 for ipng-dist; Fri, 15 Feb 2002 01:06:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F96BKL006790 for ; Fri, 15 Feb 2002 01:06:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17021 for ; Fri, 15 Feb 2002 01:06:13 -0800 (PST) Received: from wireless.cs.twsu.edu (wireless.cs.twsu.edu [156.26.10.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15928 for ; Fri, 15 Feb 2002 02:06:12 -0700 (MST) Received: from localhost (12772aba1bc030dc4332798d022f55b0@localhost.cs.twsu.edu [127.0.0.1]) by wireless.cs.twsu.edu (8.12.2/(basit)) with ESMTP id g1F96Y0m041154 for ; Fri, 15 Feb 2002 03:06:34 -0600 (CST) (envelope-from basit@basit.cc) Date: Fri, 15 Feb 2002 03:06:34 -0600 (CST) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: dynamic dns update / rtdavd In-Reply-To: <1749.1013750041@brandenburg.cs.mu.OZ.AU> Message-ID: <20020215030435.Q41010-100000@wireless.cs.twsu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Just want to know that if its possible to dynamically update dns if we are assigning ipv6 addresses dynamically by router advertisements(for e.g rtdavd or zebra that finally assignes a EUI64+ compaitable ipv6 address) kinda like DHCP mechanism. DHCP has a support for dynamic dns updates though .. so want to know about it in ipv6.. thanks -basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 02:28:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FASPKL007064 for ; Fri, 15 Feb 2002 02:28:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FASPr0007063 for ipng-dist; Fri, 15 Feb 2002 02:28:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FASLKL007055 for ; Fri, 15 Feb 2002 02:28:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20480 for ; Fri, 15 Feb 2002 02:28:24 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA29358 for ; Fri, 15 Feb 2002 03:28:22 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4103VJ>; Fri, 15 Feb 2002 11:16:19 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95CE9@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com Cc: shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 11:16:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-70b42315-215f-11d6-b1e5-00508b69ab48" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-70b42315-215f-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B609.C998CDC0" ------_=_NextPart_001_01C1B609.C998CDC0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable "PD (Automatic Prefix Delegation)" doesn't specify any means to set the prefix pool the routers rely on for delegation, apart from a manual = setting. The DHCPv6 option could be used in this aim, and would be therefore complementary to PD... Moreover PD also deals with routing protocol negocation, and does then = more than just prefix delegation... This point is interesting in so far as = the reachability of the subnet(s) corresponding to the delegated prefix = must be achieved in a way or another... Yoann -----Message d'origine----- De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Envoy=E9 : jeudi 14 f=E9vrier 2002 04:52 =C0 : Lilian Fernandes; ipng@sunroof.eng.sun.com Cc : shouchun@us.ibm.com Objet : Re: PPP and Global Addresses "PD (Automatic Prefix Delegation)" is one of the choices. draft-haberman-ipngwg-auto-prefix-01.txt http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix= -01. txt To solve all the configuration issues with DHCPv6 might be another good choice, but I guess PD be a minimum requirement for those who want an automatic prefix delegation mechanism for (for example) IPv6 access services, and DHCPv6 would be an option for those who want more. ---Toshi Yamasaki / NTT Communications > Hi, > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC = talks > about the negotiation of the Interface-Identifier and specifies the > Interface-Identifier Configuration Option. In this case the upper 64 = bits > are just fe80:: > > It does not mention if there is any standard way to configure a > global/site-local prefix on a point-to-point link i.e. are there > configuration options to let one side tell the other about a global > prefix? > > Or is it just left upto the users at both ends to decide on a prefix > somehow and then configure it on each end? > > I'm sorry if there is an RFC about this that I missed... > > Thanks, > Lilian > > _____________________________________________________________________ > > Lilian Fernandes > AIX TCP/IP Development - IBM Austin > Tel: 512-838-7966 Fax: 512-838-3509 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1B609.C998CDC0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

"PD (Automatic Prefix Delegation)" doesn't = specify any means to set the prefix pool the routers rely on for = delegation, apart from a manual setting.

The DHCPv6 option could be used in this aim, and = would be therefore complementary to PD...
Moreover PD also deals with routing protocol = negocation, and does then more than just prefix delegation... This = point is interesting in so far as the reachability of the subnet(s) = corresponding to the delegated prefix must be achieved in a way or = another...

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com]=
Envoy=E9 : jeudi 14 f=E9vrier 2002 04:52
=C0 : Lilian Fernandes; = ipng@sunroof.eng.sun.com
Cc : shouchun@us.ibm.com
Objet : Re: PPP and Global Addresses


"PD (Automatic Prefix Delegation)" is one = of the choices.

draft-haberman-ipngwg-auto-prefix-01.txt
http://search.ietf.org/internet-drafts/draft-haberman-= ipngwg-auto-prefix-01.
txt

To solve all the configuration issues with DHCPv6 = might be another good
choice, but I guess PD be a minimum requirement for = those who want an
automatic prefix delegation mechanism for (for = example) IPv6 access
services,  and DHCPv6 would be an option for = those who want more.

---Toshi Yamasaki / NTT Communications

> Hi,
>
> I have a question about RFC2472 - "IP = Version 6 over PPP". The RFC talks
> about the negotiation of the = Interface-Identifier and specifies the
> Interface-Identifier Configuration Option. In = this case the upper 64 bits
> are just fe80::
>
> It does not mention if there is any standard = way to configure a
> global/site-local prefix on a point-to-point = link i.e. are there
> configuration options to let one side tell the = other about a global
> prefix?
>
> Or is it just left upto the users at both ends = to decide on a prefix
> somehow and then configure it on each = end?
>
> I'm sorry if there is an RFC about this that I = missed...
>
> Thanks,
> Lilian
>
> = _____________________________________________________________________
>
> Lilian Fernandes
> AIX TCP/IP Development - IBM Austin
> Tel: 512-838-7966 Fax: 512-838-3509
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>
>

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1B609.C998CDC0-- ------=_NextPartTM-000-70b42315-215f-11d6-b1e5-00508b69ab48-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 02:28:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FASLKL007054 for ; Fri, 15 Feb 2002 02:28:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FASLdd007053 for ipng-dist; Fri, 15 Feb 2002 02:28:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FASIKL007046 for ; Fri, 15 Feb 2002 02:28:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15459 for ; Fri, 15 Feb 2002 02:28:21 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA22898 for ; Fri, 15 Feb 2002 02:28:20 -0800 (PST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4103VA>; Fri, 15 Feb 2002 11:15:59 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E3D52A@lat3721.rd.francetelecom.fr> From: BINET David FTRD/DMI/CAE To: "'Ole Troan'" , Francis Dupont Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 11:15:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-70b42311-215f-11d6-b1e5-00508b69ab48" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-70b42311-215f-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B609.C0B17220" ------_=_NextPart_001_01C1B609.C0B17220 Content-Type: text/plain I did not attend the IPng meeting in May 2001 in Redmond and in the minutes I do not see the reasons why DHCPv6 protocol is not appropriate for router prefix delegation. For several contexts, I think that we need some protocols or some extensions to make the prefix router delegation possible, and as it has been proposed by Ole, the new DHCP options can fit the needs. So, what are the reasons why DHCPv6 is not appropriate for such use ? Thanks David Binet -----Message d'origine----- De : Ole Troan [mailto:ot@cisco.com] Envoye : jeudi 14 fevrier 2002 20:34 A : Francis Dupont Cc : Lilian Fernandes; ipng@sunroof.eng.sun.com; shouchun@us.ibm.com Objet : Re: PPP and Global Addresses > In your previous mail you wrote: > > > http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt > > (search for Dialup Architecture, note this is my last attempt to find > > an usefulness to DHCPv6 :-). > > we're just about to suggest a couple of new DHCPv6 options for this > purpose. > > => you may but don't forget the vote was 0 (zero) in favour of DHCPv6 > and at least Steve Deering is publicly strongly opposed to use DHCPv6 > for router configuration. I'll let Steve speak for himself. it turns out that router to router prefix delegation has a number of conceptual similarities with statefull address assignment. instead of making a new protocol evolve into DHCP under a different name, I suggest we reconsider the use of DHCP. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1B609.C0B17220 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

I did not attend the IPng meeting in May 2001 in = Redmond and in the minutes I do not see the reasons why DHCPv6 protocol = is not appropriate for router prefix delegation.

For several contexts, I think that we need some = protocols or some extensions to make the prefix router delegation = possible, and as it has been proposed by Ole, the new DHCP options can = fit the needs.

So, what are the reasons why DHCPv6 is not = appropriate for such use ?

Thanks
David Binet 

-----Message d'origine-----
De : Ole Troan [mailto:ot@cisco.com]
Envoye : jeudi 14 fevrier 2002 20:34
A : Francis Dupont
Cc : Lilian Fernandes; ipng@sunroof.eng.sun.com; = shouchun@us.ibm.com
Objet : Re: PPP and Global Addresses


>  In your previous mail you wrote:
>
>    > http://playground.sun.com/pub/ipng/html/minutes/ipng-m= eeting-may2001.txt
>    > (search for Dialup = Architecture, note this is my last attempt to find
>    > an usefulness to DHCPv6 = :-).
>   
>    we're just about to suggest a = couple of new DHCPv6 options for this
>    purpose.
>   
> =3D> you may but don't forget the vote was 0 = (zero) in favour of DHCPv6
> and at least Steve Deering is publicly strongly = opposed to use DHCPv6
> for router configuration.

I'll let Steve speak for himself.

it turns out that router to router prefix delegation = has a number of
conceptual similarities with statefull address = assignment. instead of
making a new protocol evolve into DHCP under a = different name, I
suggest we reconsider the use of DHCP.

/ot
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1B609.C0B17220-- ------=_NextPartTM-000-70b42311-215f-11d6-b1e5-00508b69ab48-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 02:44:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAiWKL007117 for ; Fri, 15 Feb 2002 02:44:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FAiWt1007116 for ipng-dist; Fri, 15 Feb 2002 02:44:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAiTKL007109 for ; Fri, 15 Feb 2002 02:44:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05410 for ; Fri, 15 Feb 2002 02:44:31 -0800 (PST) Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [210.163.32.54]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22202 for ; Fri, 15 Feb 2002 02:44:30 -0800 (PST) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail2.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id TAA24266; Fri, 15 Feb 2002 19:44:25 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id TAA02794; Fri, 15 Feb 2002 19:44:25 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id TAA02790; Fri, 15 Feb 2002 19:44:24 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id TAA21371; Fri, 15 Feb 2002 19:44:24 +0900 (JST) Message-ID: <02fd01c1b60d$c5481470$30a0240a@local> From: "Yamasaki Toshi" To: "NOISETTE Yoann FTRD/DMI/CAE" , "Lilian Fernandes" , Cc: References: <91A311FF6A85D3118DDF0060080C3D8202C95CE6@lat3721.rd.francetelecom.fr> Subject: Re: PPP and Global Addresses Date: Fri, 15 Feb 2002 19:43:34 +0900 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "PD (Automatic Prefix Delegation)" doesn't specify any means to set the > prefix pool the routers rely on for delegation, apart from a manual setting. Could you kindly explain what you mean by this sentence in another way? I did't get the point... > The DHCPv6 option could be used in this aim, and would be therefore > complementary to PD... > Moreover PD also deals with routing protocol negocation, and does then more > than just prefix delegation... This point is interesting in so far as the > reachability of the subnet(s) corresponding to the delegated prefix must be > achieved in a way or another... I believe PD and DHCP are not competing, but can live together, like RA and DHCP can do so at a subnet. My understanding is that PD is "third-party-serverless autoconfig" or "third-party-server independent autoconfig" and DHCP is "third-party-server dependent", because PD is for routers which actually delegate and route the delegated prefix, and DHCP is not necessarily so. > > Yoann > > -----Message d'origine----- > De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] > Envoye : jeudi 14 fevrier 2002 04:52 > A : Lilian Fernandes; ipng@sunroof.eng.sun.com > Cc : shouchun@us.ibm.com > Objet : Re: PPP and Global Addresses > > > > "PD (Automatic Prefix Delegation)" is one of the choices. > > draft-haberman-ipngwg-auto-prefix-01.txt > http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-01. > txt > > To solve all the configuration issues with DHCPv6 might be another good > choice, but I guess PD be a minimum requirement for those who want an > automatic prefix delegation mechanism for (for example) IPv6 access > services, and DHCPv6 would be an option for those who want more. > > ---Toshi Yamasaki / NTT Communications > > > Hi, > > > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks > > about the negotiation of the Interface-Identifier and specifies the > > Interface-Identifier Configuration Option. In this case the upper 64 bits > > are just fe80:: > > > > It does not mention if there is any standard way to configure a > > global/site-local prefix on a point-to-point link i.e. are there > > configuration options to let one side tell the other about a global > > prefix? > > > > Or is it just left upto the users at both ends to decide on a prefix > > somehow and then configure it on each end? > > > > I'm sorry if there is an RFC about this that I missed... > > > > Thanks, > > Lilian > > > > _____________________________________________________________________ > > > > Lilian Fernandes > > AIX TCP/IP Development - IBM Austin > > Tel: 512-838-7966 Fax: 512-838-3509 > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 02:55:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAtkKL007190 for ; Fri, 15 Feb 2002 02:55:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FAtkWf007189 for ipng-dist; Fri, 15 Feb 2002 02:55:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAthKL007182 for ; Fri, 15 Feb 2002 02:55:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04503 for ; Fri, 15 Feb 2002 02:55:45 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA08879 for ; Fri, 15 Feb 2002 03:55:43 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4W5BGN>; Fri, 15 Feb 2002 11:55:22 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95CEB@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Yamasaki Toshi'" , NOISETTE Yoann FTRD/DMI/CAE , Lilian Fernandes , ipng@sunroof.eng.sun.com Cc: shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 11:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cf28115e-209a-11d6-ac1f-00508b692753" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-cf28115e-209a-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B60F.3DF278B0" ------_=_NextPart_001_01C1B60F.3DF278B0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The draft-haberman-ipngwg-auto-prefix-01.txt says : "4.4 Prefix Delegation=20 =20 After the request is verified to be acceptable, the Delegating=20 Router allocates the requested prefix size from its pool of=20 available addresses. The creation and management of that pool is=20 beyond the scope of this document, but it can be supposed that=20 minimalistically a Delegating Router will be statically configured=20 with a fixed pool." What I meant is that the pool used by the Delegating router, in which = it takes the prefix it delegates to Requesting routers, could be set using = the DHCPv6 option for prefix delegation. Actually, only static (I = understand "manual") configuration is considered. For instance, when a Delegating router is asked for a prefix, and can't answer because it doesn't have enough resources any more, it could then = rely on the DHCPv6 option to get another pool... and then proceed to the = required Prefix Delegation.=20 Sorry this was not clear, hope it is now ;-) Yoann -----Message d'origine----- De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Envoy=E9 : vendredi 15 f=E9vrier 2002 11:44 =C0 : NOISETTE Yoann FTRD/DMI/CAE; Lilian Fernandes; ipng@sunroof.eng.sun.com Cc : shouchun@us.ibm.com Objet : Re: PPP and Global Addresses > "PD (Automatic Prefix Delegation)" doesn't specify any means to set = the > prefix pool the routers rely on for delegation, apart from a manual setting. Could you kindly explain what you mean by this sentence in another way? = I did't get the point... > The DHCPv6 option could be used in this aim, and would be therefore > complementary to PD... > Moreover PD also deals with routing protocol negocation, and does = then more > than just prefix delegation... This point is interesting in so far as = the > reachability of the subnet(s) corresponding to the delegated prefix = must be > achieved in a way or another... I believe PD and DHCP are not competing, but can live together, like RA = and DHCP can do so at a subnet. My understanding is that PD is "third-party-serverless autoconfig" or "third-party-server independent autoconfig" and DHCP is = "third-party-server dependent", because PD is for routers which actually delegate and route = the delegated prefix, and DHCP is not necessarily so. > > Yoann > > -----Message d'origine----- > De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] > Envoye : jeudi 14 fevrier 2002 04:52 > A : Lilian Fernandes; ipng@sunroof.eng.sun.com > Cc : shouchun@us.ibm.com > Objet : Re: PPP and Global Addresses > > > > "PD (Automatic Prefix Delegation)" is one of the choices. > > draft-haberman-ipngwg-auto-prefix-01.txt > http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix= -01. > txt > > To solve all the configuration issues with DHCPv6 might be another = good > choice, but I guess PD be a minimum requirement for those who want an > automatic prefix delegation mechanism for (for example) IPv6 access > services, and DHCPv6 would be an option for those who want more. > > ---Toshi Yamasaki / NTT Communications > > > Hi, > > > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC = talks > > about the negotiation of the Interface-Identifier and specifies the > > Interface-Identifier Configuration Option. In this case the upper = 64 bits > > are just fe80:: > > > > It does not mention if there is any standard way to configure a > > global/site-local prefix on a point-to-point link i.e. are there > > configuration options to let one side tell the other about a global > > prefix? > > > > Or is it just left upto the users at both ends to decide on a = prefix > > somehow and then configure it on each end? > > > > I'm sorry if there is an RFC about this that I missed... > > > > Thanks, > > Lilian > > > > = _____________________________________________________________________ > > > > Lilian Fernandes > > AIX TCP/IP Development - IBM Austin > > Tel: 512-838-7966 Fax: 512-838-3509 > > > > > > = -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > = -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > > > ------_=_NextPart_001_01C1B60F.3DF278B0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

The draft-haberman-ipngwg-auto-prefix-01.txt says = :

"4.4 Prefix Delegation
   
   After the request is verified to be = acceptable, the Delegating
   Router allocates the requested prefix = size from its pool of
   available addresses. The creation and = management of that pool is
   beyond the scope of this document, but = it can be supposed that
   minimalistically a Delegating Router = will be statically configured
   with a fixed pool."

What I meant is that the pool used by the Delegating = router, in which it takes the prefix it delegates to Requesting = routers, could be set using the DHCPv6 option for prefix delegation. = Actually, only static (I understand "manual") configuration = is considered.

For instance, when a Delegating router is asked for a = prefix, and can't answer because it doesn't have enough resources any = more, it could then rely on the DHCPv6 option to get another pool... = and then proceed to the required Prefix Delegation.

Sorry this was not clear, hope it is now ;-)

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com]=
Envoy=E9 : vendredi 15 f=E9vrier 2002 11:44
=C0 : NOISETTE Yoann FTRD/DMI/CAE; Lilian = Fernandes;
ipng@sunroof.eng.sun.com
Cc : shouchun@us.ibm.com
Objet : Re: PPP and Global Addresses


> "PD (Automatic Prefix Delegation)" = doesn't specify any means to set the
> prefix pool the routers rely on for delegation, = apart from a manual
setting.

Could you kindly explain what you mean by this = sentence in another way? I
did't get the point...

> The DHCPv6 option could be used in this aim, and = would be therefore
> complementary to PD...
> Moreover PD also deals with routing protocol = negocation, and does then
more
> than just prefix delegation... This point is = interesting in so far as the
> reachability of the subnet(s) corresponding to = the delegated prefix must
be
> achieved in a way or another...

I believe PD and DHCP are not competing, but can live = together, like RA and
DHCP can do so at a subnet.

My understanding is that PD is = "third-party-serverless autoconfig" or
"third-party-server independent = autoconfig" and DHCP is "third-party-server
dependent", because PD is for routers which = actually delegate and route the
delegated prefix, and DHCP is not necessarily = so.

>
> Yoann
>
> -----Message d'origine-----
> De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com]=
> Envoye : jeudi 14 fevrier 2002 04:52
> A : Lilian Fernandes; = ipng@sunroof.eng.sun.com
> Cc : shouchun@us.ibm.com
> Objet : Re: PPP and Global Addresses
>
>
>
> "PD (Automatic Prefix Delegation)" is = one of the choices.
>
> draft-haberman-ipngwg-auto-prefix-01.txt
>
http://search.ietf.org/internet-drafts/draft-haberman-= ipngwg-auto-prefix-01.
> txt
>
> To solve all the configuration issues with = DHCPv6 might be another good
> choice, but I guess PD be a minimum requirement = for those who want an
> automatic prefix delegation mechanism for (for = example) IPv6 access
> services,  and DHCPv6 would be an option = for those who want more.
>
> ---Toshi Yamasaki / NTT Communications
>
> > Hi,
> >
> > I have a question about RFC2472 - "IP = Version 6 over PPP". The RFC talks
> > about the negotiation of the = Interface-Identifier and specifies the
> > Interface-Identifier Configuration Option. = In this case the upper 64
bits
> > are just fe80::
> >
> > It does not mention if there is any = standard way to configure a
> > global/site-local prefix on a = point-to-point link i.e. are there
> > configuration options to let one side tell = the other about a global
> > prefix?
> >
> > Or is it just left upto the users at both = ends to decide on a prefix
> > somehow and then configure it on each = end?
> >
> > I'm sorry if there is an RFC about this = that I missed...
> >
> > Thanks,
> > Lilian
> >
> > = _____________________________________________________________________
> >
> > Lilian Fernandes
> > AIX TCP/IP Development - IBM Austin
> > Tel: 512-838-7966 Fax: 512-838-3509
> >
> >
> > = --------------------------------------------------------------------
> > IETF IPng Working Group Mailing = List
> > IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> > FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> > = --------------------------------------------------------------------
> >
> >
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>
>
>
>
>

------_=_NextPart_001_01C1B60F.3DF278B0-- ------=_NextPartTM-000-cf28115e-209a-11d6-ac1f-00508b692753-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 06:34:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FEYQKL007963 for ; Fri, 15 Feb 2002 06:34:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FEYQbS007962 for ipng-dist; Fri, 15 Feb 2002 06:34:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FEYNKL007955 for ; Fri, 15 Feb 2002 06:34:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17936 for ; Fri, 15 Feb 2002 06:34:25 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25780 for ; Fri, 15 Feb 2002 07:34:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FEYIk14629; Fri, 15 Feb 2002 15:34:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA11903; Fri, 15 Feb 2002 15:34:19 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FEYHg22899; Fri, 15 Feb 2002 15:34:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151434.g1FEYHg22899@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sean.lin@alliedtelesyn.co.nz cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and VLAN link-local addresses In-reply-to: Your message of Fri, 15 Feb 2002 11:53:24 +1300. <3C6CF67F.30.4C1A3CAD@localhost> Date: Fri, 15 Feb 2002 15:34:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I was wondering if this has been mentioned before. Will there be adverse effects( is this allowed in the first place?) => this is NOT allowed and is not useful (link-local addresses are bound to a link, there is no need to say which link inside the address). so as to have the last 32 bits of the hgiher 64 bits of the link-local address to represent the interface ID => I believe you mean the interface index. Was proposed and rejected. IMHO this is a very bad idea because the interface index is local to the node. or the VLAN => a VLAN is a link. or PPP ID. => what is a PPP ID? Also, I take it that the global bit in the eui-64 identifier will still be set if the above format is allowed? => the "g" bit of the modified EUI-64 format is a property of the interface ID, not of the address. The only relation between addresses and interface ID format is the modified EUI-64 is mandatory for interface IDs which are part of unicast (anycast too) addresses which are not in the ::/3 prefix. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 06:52:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FEqaKL007997 for ; Fri, 15 Feb 2002 06:52:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FEqak3007996 for ipng-dist; Fri, 15 Feb 2002 06:52:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FEqXKL007989 for ; Fri, 15 Feb 2002 06:52:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10507 for ; Fri, 15 Feb 2002 06:52:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06006 for ; Fri, 15 Feb 2002 07:52:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FEqRk16711; Fri, 15 Feb 2002 15:52:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA12348; Fri, 15 Feb 2002 15:52:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FEqRg22986; Fri, 15 Feb 2002 15:52:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151452.g1FEqRg22986@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: NAKAJIMA Nobuyasu cc: ipng@sunroof.eng.sun.com Subject: Re: sending packets before completing DAD In-reply-to: Your message of Thu, 14 Feb 2002 19:32:03 EST. <20020214.193203.91280686.nobuyasu.nakajima@toshiba.co.jp> Date: Fri, 15 Feb 2002 15:52:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: My question is whether the node in the process of DAD can send the packets other than Neighbor Solicitations for the purpose of DAD. => it can (it should for instance send some MLD joins) but it must not use the tentative address (i.e. MLD joins should get the unspecified address as the source address, same thing for router solicitations). RFC2462 says that the tentative address cannot be assigned to the interface. So I think the node cannot send packets before completing DAD. Is this interpretation correct? => modulo some exceptions for some ICMPv6 packets which can use the :: source, this is 100% true. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 07:51:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFpQKL008627 for ; Fri, 15 Feb 2002 07:51:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFpQHd008626 for ipng-dist; Fri, 15 Feb 2002 07:51:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFpMKL008619 for ; Fri, 15 Feb 2002 07:51:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04830 for ; Fri, 15 Feb 2002 07:51:24 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06598 for ; Fri, 15 Feb 2002 08:51:24 -0700 (MST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA29356 for ; Fri, 15 Feb 2002 09:46:29 -0600 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.226.185]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1FFpMa110346 for ; Fri, 15 Feb 2002 10:51:23 -0500 Importance: Normal Sensitivity: Subject: site local addresses To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Fri, 15 Feb 2002 10:48:37 -0500 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/15/2002 10:51:22 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1F2DFC50D338f9e8a93df938690918c0ABBE1F2DFC50D33" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE1F2DFC50D338f9e8a93df938690918c0ABBE1F2DFC50D33 Content-type: text/plain; charset=US-ASCII >From draft-ietf-ipngwg-addr-arch-v3-07 in section 2.4 it states: Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast 11111111 FF00::/8 2.7 Link-local unicast 1111111010 FE80::/10 2.5.6 Site-local unicast 1111111011 FEC0::/10 2.5.6 Global unicast (everything else) Then in section 2.5.6 it states Site-Local addresses have the following format: | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ So, is it sufficient to say any address that starts with FEC0::/10 is a site local address or does it have to be FEC0::48? Lori --0__=0ABBE1F2DFC50D338f9e8a93df938690918c0ABBE1F2DFC50D33 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

From draft-ietf-ipngwg-addr-arch-v3-07 in section 2.4 it states:


Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-local unicast 1111111010 FE80::/10 2.5.6
Site-local unicast 1111111011 FEC0::/10 2.5.6
Global unicast (everything else)


Then in section 2.5.6 it states

Site-Local addresses have the following format:

| 10 |
| bits | 38 bits | 16 bits | 64 bits |
+----------+-------------+-----------+----------------------------+
|1111111011| 0 | subnet ID | interface ID |
+----------+-------------+-----------+----------------------------+


So, is it sufficient to say any address that starts with FEC0::/10 is a site local address or does it have to be FEC0::48?

Lori --0__=0ABBE1F2DFC50D338f9e8a93df938690918c0ABBE1F2DFC50D33-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 07:55:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFtjKL008679 for ; Fri, 15 Feb 2002 07:55:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFtirR008678 for ipng-dist; Fri, 15 Feb 2002 07:55:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFteKL008665 for ; Fri, 15 Feb 2002 07:55:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06143 for ; Fri, 15 Feb 2002 07:55:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17460 for ; Fri, 15 Feb 2002 08:55:41 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FFtQk23881; Fri, 15 Feb 2002 16:55:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA13664; Fri, 15 Feb 2002 16:55:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FFtPg23468; Fri, 15 Feb 2002 16:55:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151555.g1FFtPg23468@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: NOISETTE Yoann FTRD/DMI/CAE cc: "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Fri, 15 Feb 2002 11:55:12 +0100. <91A311FF6A85D3118DDF0060080C3D8202C95CEB@lat3721.rd.francetelecom.fr> Date: Fri, 15 Feb 2002 16:55:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: "... The creation and management of that pool is beyond the scope of this document, but it can be supposed that minimalistically a Delegating Router will be statically configured with a fixed pool." What I meant is that the pool used by the Delegating router, in which it takes the prefix it delegates to Requesting routers, could be set using the DHCPv6 option for prefix delegation. Actually, only static (I understand "manual") configuration is considered. => this notion of static (DHCP terminology) / manual (common terminology) allocation is more important than one can believe. The difference between BOOTP and DHCP is the introduction of the dynamic (DHCP terminology) allocation. My main concern about DHCPv6 is the dynamic allocation makes sense only for a scarce resource: this is the case for IPv4 addresses but definitively *not* for IPv6 addresses... So DHCPv6 is basically useless (and in the real world not used at all :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:00:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG0cKL008808 for ; Fri, 15 Feb 2002 08:00:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FG0cIj008807 for ipng-dist; Fri, 15 Feb 2002 08:00:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG0YKL008797 for ; Fri, 15 Feb 2002 08:00:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09686 for ; Fri, 15 Feb 2002 08:00:36 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11341 for ; Fri, 15 Feb 2002 09:00:36 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FG0DN14851; Fri, 15 Feb 2002 10:00:13 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CPDV>; Fri, 15 Feb 2002 10:00:13 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A0311A12A@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Francis Dupont'" , NOISETTE Yoann FTRD/DMI/CAE Cc: "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 10:00:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B639.DDD06DE0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B639.DDD06DE0 Content-Type: text/plain; charset="iso-8859-1" Not even when the M and O bits in the Router Advertisement message are configured to indicate a combination of stateless and stateful autoconfiguration such that DHCPv6 provides options (e.g., SIP server option) but not an actual address? -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Friday, February 15, 2002 9:55 AM To: NOISETTE Yoann FTRD/DMI/CAE Cc: 'Yamasaki Toshi'; Lilian Fernandes; ipng@sunroof.eng.sun.com; shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In your previous mail you wrote: "... The creation and management of that pool is beyond the scope of this document, but it can be supposed that minimalistically a Delegating Router will be statically configured with a fixed pool." What I meant is that the pool used by the Delegating router, in which it takes the prefix it delegates to Requesting routers, could be set using the DHCPv6 option for prefix delegation. Actually, only static (I understand "manual") configuration is considered. => this notion of static (DHCP terminology) / manual (common terminology) allocation is more important than one can believe. The difference between BOOTP and DHCP is the introduction of the dynamic (DHCP terminology) allocation. My main concern about DHCPv6 is the dynamic allocation makes sense only for a scarce resource: this is the case for IPv4 addresses but definitively *not* for IPv6 addresses... So DHCPv6 is basically useless (and in the real world not used at all :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1B639.DDD06DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

Not even when the M and O bits in the Router = Advertisement message are configured to indicate a combination of = stateless and stateful autoconfiguration such that DHCPv6 provides = options (e.g., SIP server option) but not an actual address?

-----Original Message-----
From: Francis Dupont [mailto:Francis.Dupont@en= st-bretagne.fr]
Sent: Friday, February 15, 2002 9:55 AM
To: NOISETTE Yoann FTRD/DMI/CAE
Cc: 'Yamasaki Toshi'; Lilian Fernandes; = ipng@sunroof.eng.sun.com;
shouchun@us.ibm.com
Subject: Re: PPP and Global Addresses


 In your previous mail you wrote:

      "... The creation = and management of that pool is
      beyond the scope of = this document, but it can be supposed that
      minimalistically a = Delegating Router will be statically configured
      with a fixed = pool."
  
   What I meant is that the pool used by = the Delegating router, in which it
   takes the prefix it delegates to = Requesting routers, could be set using the
   DHCPv6 option for prefix delegation. = Actually, only static (I understand
   "manual") configuration is = considered.

=3D> this notion of static (DHCP terminology) / = manual (common terminology)
allocation is more important than one can believe. = The difference between
BOOTP and DHCP is the introduction of the dynamic = (DHCP terminology)
allocation. My main concern about DHCPv6 is the = dynamic allocation
makes sense only for a scarce resource: this is the = case for IPv4
addresses but definitively *not* for IPv6 = addresses... So DHCPv6 is
basically useless (and in the real world not used at = all :-).

Regards

Francis.Dupont@enst-bretagne.fr
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1B639.DDD06DE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:06:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG6dKL008860 for ; Fri, 15 Feb 2002 08:06:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FG6dfI008859 for ipng-dist; Fri, 15 Feb 2002 08:06:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG6aKL008852 for ; Fri, 15 Feb 2002 08:06:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27213 for ; Fri, 15 Feb 2002 08:06:38 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23011 for ; Fri, 15 Feb 2002 09:06:38 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id LAA27132 for ; Fri, 15 Feb 2002 11:06:36 -0500 (EST) From: "Dr. Subrata Goswami" To: Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 08:07:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200202151555.g1FFtPg23468@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mr. Dupont, DHCP originally started with allowing dynamic IP address allocation. A secondary benefit of utility is in network operations, it is impossible to manually assign IP address to 100's of hosts let alone 1,000,000's that IPv6 would allow. This about a large network operator, how are they going to manage their asset of IP address pool - send a person to manually configure each host, that is silly. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Friday, February 15, 2002 7:55 AM To: NOISETTE Yoann FTRD/DMI/CAE Cc: 'Yamasaki Toshi'; Lilian Fernandes; ipng@sunroof.eng.sun.com; shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In your previous mail you wrote: "... The creation and management of that pool is beyond the scope of this document, but it can be supposed that minimalistically a Delegating Router will be statically configured with a fixed pool." What I meant is that the pool used by the Delegating router, in which it takes the prefix it delegates to Requesting routers, could be set using the DHCPv6 option for prefix delegation. Actually, only static (I understand "manual") configuration is considered. => this notion of static (DHCP terminology) / manual (common terminology) allocation is more important than one can believe. The difference between BOOTP and DHCP is the introduction of the dynamic (DHCP terminology) allocation. My main concern about DHCPv6 is the dynamic allocation makes sense only for a scarce resource: this is the case for IPv4 addresses but definitively *not* for IPv6 addresses... So DHCPv6 is basically useless (and in the real world not used at all :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:41:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGfpKL009283 for ; Fri, 15 Feb 2002 08:41:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGfppU009282 for ipng-dist; Fri, 15 Feb 2002 08:41:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGflKL009272 for ; Fri, 15 Feb 2002 08:41:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17112 for ; Fri, 15 Feb 2002 08:41:50 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12471 for ; Fri, 15 Feb 2002 09:41:49 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FGfik29918; Fri, 15 Feb 2002 17:41:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA14765; Fri, 15 Feb 2002 17:41:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FGfig23908; Fri, 15 Feb 2002 17:41:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151641.g1FGfig23908@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Lori Napoli" cc: ipng@sunroof.eng.sun.com Subject: Re: site local addresses In-reply-to: Your message of Fri, 15 Feb 2002 10:48:37 EST. Date: Fri, 15 Feb 2002 17:41:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So, is it sufficient to say any address that starts with FEC0::/10 is a site local address or does it have to be FEC0::48? => I believe the 07 draft clearly specifies that anything which is in fec0::/10 but not in fec0::/48 is reserved, i.e. an illegal site-local address. Regards Francis.Dupont@enst-bretagne.fr PS: (for English gurus), I propose s/illegal/malformed/ ? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:50:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGolKL009543 for ; Fri, 15 Feb 2002 08:50:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGol2M009542 for ipng-dist; Fri, 15 Feb 2002 08:50:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGoiKL009535 for ; Fri, 15 Feb 2002 08:50:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19253 for ; Fri, 15 Feb 2002 08:50:46 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01639 for ; Fri, 15 Feb 2002 09:50:43 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FGoPk30855; Fri, 15 Feb 2002 17:50:25 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA14957; Fri, 15 Feb 2002 17:50:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FGoPg23973; Fri, 15 Feb 2002 17:50:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151650.g1FGoPg23973@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Peter Barany" cc: NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Fri, 15 Feb 2002 10:00:19 CST. <1B54FA3A2709D51195C800508BF9386A0311A12A@zrc2c000.us.nortel.com> Date: Fri, 15 Feb 2002 17:50:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Not even when the M and O bits in the Router Advertisement message are configured to indicate a combination of stateless and stateful autoconfiguration such that DHCPv6 provides options (e.g., SIP server option) but not an actual address? => look at SLPv2 (RFC 2608) and DNS SRV RRs (RFC 2782) for service location tools which are *really* used. I am tired to find alternative uses of DHCPv6 when its main use (and 90% of the protocol) makes no sense. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:54:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGskKL009605 for ; Fri, 15 Feb 2002 08:54:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGskWi009604 for ipng-dist; Fri, 15 Feb 2002 08:54:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGsgKL009597 for ; Fri, 15 Feb 2002 08:54:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09146 for ; Fri, 15 Feb 2002 08:54:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12075 for ; Fri, 15 Feb 2002 09:54:44 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1FGsak31208; Fri, 15 Feb 2002 17:54:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA15047; Fri, 15 Feb 2002 17:54:36 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1FGsag24011; Fri, 15 Feb 2002 17:54:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202151654.g1FGsag24011@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dr. Subrata Goswami" cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Fri, 15 Feb 2002 08:07:35 PST. Date: Fri, 15 Feb 2002 17:54:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Mr. Dupont, DHCP originally started with allowing dynamic IP address allocation. A secondary benefit of utility is in network operations, it is impossible to manually assign IP address to 100's of hosts let alone 1,000,000's that IPv6 would allow. This about a large network operator, how are they going to manage their asset of IP address pool - send a person to manually configure each host, that is silly. => RFC 2462 "IPv6 Stateless Address Autoconfiguration". Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 08:59:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGxRKL009654 for ; Fri, 15 Feb 2002 08:59:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGxRUh009653 for ipng-dist; Fri, 15 Feb 2002 08:59:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGxOKL009646 for ; Fri, 15 Feb 2002 08:59:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12605 for ; Fri, 15 Feb 2002 08:59:26 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03857 for ; Fri, 15 Feb 2002 08:59:26 -0800 (PST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id LAA12170 for ; Fri, 15 Feb 2002 11:59:25 -0500 (EST) From: "Dr. Subrata Goswami" To: Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 09:00:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200202151654.g1FGsag24011@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk nope, not enough for a accounting, service termination etc. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Friday, February 15, 2002 8:55 AM To: Dr. Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In your previous mail you wrote: Mr. Dupont, DHCP originally started with allowing dynamic IP address allocation. A secondary benefit of utility is in network operations, it is impossible to manually assign IP address to 100's of hosts let alone 1,000,000's that IPv6 would allow. This about a large network operator, how are they going to manage their asset of IP address pool - send a person to manually configure each host, that is silly. => RFC 2462 "IPv6 Stateless Address Autoconfiguration". Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 09:35:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHZTKL010194 for ; Fri, 15 Feb 2002 09:35:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHZTAF010190 for ipng-dist; Fri, 15 Feb 2002 09:35:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHZPKL010183 for ; Fri, 15 Feb 2002 09:35:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24829 for ; Fri, 15 Feb 2002 09:35:23 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08893 for ; Fri, 15 Feb 2002 09:35:22 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Feb 2002 09:34:45 -0800 From: "Tony Hain" To: "Abdul Basit" , Subject: RE: dynamic dns update / rtdavd Date: Fri, 15 Feb 2002 09:34:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020215030435.Q41010-100000@wireless.cs.twsu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You are asking an implementation specific question. There is nothing in either mechanism specifically targeting DDNS updates, but you will likely find products that do update dns whichever mechanism gets used. One design assumption of RA based auto-config was that nodes would most likely register themselves using DDNS, but with RFC3041 auto-config addresses, that is counter to the goal of anonymity. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Abdul Basit > Sent: Friday, February 15, 2002 1:07 AM > To: ipng@sunroof.eng.sun.com > Subject: dynamic dns update / rtdavd > > > > Hi, > > Just want to know that if its possible to dynamically update > dns if we are assigning ipv6 addresses dynamically by router > advertisements(for e.g rtdavd or zebra that finally assignes > a EUI64+ compaitable ipv6 address) kinda like DHCP mechanism. > DHCP has a support for dynamic dns updates though .. > so want to know about it in ipv6.. > > thanks > -basit > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 09:51:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHpqKL010559 for ; Fri, 15 Feb 2002 09:51:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHpqpG010558 for ipng-dist; Fri, 15 Feb 2002 09:51:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHpnKL010551 for ; Fri, 15 Feb 2002 09:51:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14480 for ; Fri, 15 Feb 2002 09:51:47 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17370 for ; Fri, 15 Feb 2002 09:51:41 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA11303; Fri, 15 Feb 2002 17:51:22 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Francis Dupont Cc: NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses References: <200202151555.g1FFtPg23468@givry.rennes.enst-bretagne.fr> From: Ole Troan Date: Fri, 15 Feb 2002 17:51:22 +0000 In-Reply-To: <200202151555.g1FFtPg23468@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Fri, 15 Feb 2002 16:55:25 +0100") Message-ID: <7t5k7tews4l.fsf@mrwint.cisco.com> Lines: 53 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > "... The creation and management of that pool is > beyond the scope of this document, but it can be supposed that > minimalistically a Delegating Router will be statically configured > with a fixed pool." > > What I meant is that the pool used by the Delegating router, in which it > takes the prefix it delegates to Requesting routers, could be set using the > DHCPv6 option for prefix delegation. Actually, only static (I understand > "manual") configuration is considered. > > => this notion of static (DHCP terminology) / manual (common terminology) > allocation is more important than one can believe. The difference between > BOOTP and DHCP is the introduction of the dynamic (DHCP terminology) > allocation. My main concern about DHCPv6 is the dynamic allocation > makes sense only for a scarce resource: this is the case for IPv4 > addresses but definitively *not* for IPv6 addresses... So DHCPv6 is > basically useless (and in the real world not used at all :-). I don't think either the ICMP PD or DHCPv6 PD drafts imply that the prefix lifetimes/leasetimes should be short. the ICMP PD draft makes a reference to delegating routers having a pool of prefixes to assign. this is perhaps an unfortunate choice of words. as it is proposed both DHCP PD and ICMP PD work in the same manner. both protocols run only on the link between delegating router and requesting router. there are a couple of ways the delegating router can use to get the prefix for the user. e.g from an AAA record, manually configured on the delegation router, from a DHCP server or from a locally configured pool. apart from a locally configured pool, where you lack stable storage, none of these imply "dynamic" allocation. both ICMP PD and DHCP PD _can_ be used for dynamic allocation but that is an operational choice. would you be happier if we renamed it to SNCP (Simple Node Configuration Protocol)? :-) for me this boils down to picking a packet format on the wire. DHCP offers a more flexible option format, is more extensible, has a defined relay mechanism, offers a Reconfigure mechanism so it is possible to poke the requesting router. I have no problem with using ICMP PD, my point is that as we move along it is going to look awfully much like DHCP. cheers, Ole -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 15 10:32:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIWIKL010895 for ; Fri, 15 Feb 2002 10:32:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FIWINf010894 for ipng-dist; Fri, 15 Feb 2002 10:32:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIWBKL010881 for ; Fri, 15 Feb 2002 10:32:11 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16128 for ; Fri, 15 Feb 2002 10:32:13 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net [4.60.69.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07759 for ; Fri, 15 Feb 2002 10:32:07 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Feb 2002 10:32:02 -0800 From: "Tony Hain" To: "Ole Troan" , "Francis Dupont" Cc: "NOISETTE Yoann FTRD/DMI/CAE" , "'Yamasaki Toshi'" , "Lilian Fernandes" , , Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 10:32:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <7t5k7tews4l.fsf@mrwint.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: > ... > would you be happier if we renamed it to SNCP (Simple Node > Configuration Protocol)? :-) Actually, yes. Routers are not hosts, so configuring routers with what is titled a host specific protocol will create more confusion than it is worth. > > for me this boils down to picking a packet format on the wire. DHCP > offers a more flexible option format, is more extensible, has a > defined relay mechanism, offers a Reconfigure mechanism so it is > possible to poke the requesting router. I have no problem with using > ICMP PD, my point is that as we move along it is going to look awfully > much like DHCP. If we are going to need a stateful protocol tied to an authentication system, using the wire format and option richness of a widely deployed protocol makes more sense than inventing a new one. At the same time, going that route requires a serious look at the defined options to find any potential security holes that may exist because there was a historical assumption that the option applied to an end system not a router. If a router requesting one of the existing options opens a big hole, we really do need a new protocol. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 16 03:21:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GBLqKL012990 for ; Sat, 16 Feb 2002 03:21:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GBLqEU012989 for ipng-dist; Sat, 16 Feb 2002 03:21:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GBLnKL012982 for ; Sat, 16 Feb 2002 03:21:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06968 for ; Sat, 16 Feb 2002 03:21:50 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27931 for ; Sat, 16 Feb 2002 03:21:49 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GBLhk10366; Sat, 16 Feb 2002 12:21:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA22015; Sat, 16 Feb 2002 12:21:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GBLgg28904; Sat, 16 Feb 2002 12:21:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161121.g1GBLgg28904@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dr. Subrata Goswami" cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Fri, 15 Feb 2002 09:00:24 PST. Date: Sat, 16 Feb 2002 12:21:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: nope, not enough for a accounting, service termination etc. => I know this argument but management is not allocation. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 16 07:50:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFouKL013446 for ; Sat, 16 Feb 2002 07:50:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFotbj013445 for ipng-dist; Sat, 16 Feb 2002 07:50:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFoqKL013438 for ; Sat, 16 Feb 2002 07:50:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10531 for ; Sat, 16 Feb 2002 07:50:54 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29127 for ; Sat, 16 Feb 2002 08:50:53 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1GFoJr11053; Sat, 16 Feb 2002 17:50:23 +0200 Date: Sat, 16 Feb 2002 17:50:18 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Ole Troan , Francis Dupont , NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , , Subject: RE: PPP and Global Addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Feb 2002, Tony Hain wrote: > Ole Troan wrote: > > ... > > would you be happier if we renamed it to SNCP (Simple Node > > Configuration Protocol)? :-) > > Actually, yes. Routers are not hosts, so configuring routers with what > is titled a host specific protocol will create more confusion than it is > worth. Just a point: the value of router/host toggle is interface-specific. This was dicussed, hmm, probably around 6-9 months ago here in the context of RFC2461. I also think DHCP and what not should not be used for router configuration. > > for me this boils down to picking a packet format on the wire. DHCP > > offers a more flexible option format, is more extensible, has a > > defined relay mechanism, offers a Reconfigure mechanism so it is > > possible to poke the requesting router. I have no problem with using > > ICMP PD, my point is that as we move along it is going to look awfully > > much like DHCP. > > If we are going to need a stateful protocol tied to an authentication > system, using the wire format and option richness of a widely deployed > protocol makes more sense than inventing a new one. At the same time, > going that route requires a serious look at the defined options to find > any potential security holes that may exist because there was a > historical assumption that the option applied to an end system not a > router. If a router requesting one of the existing options opens a big > hole, we really do need a new protocol. > > Tony > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 16 09:24:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GHObKL013860 for ; Sat, 16 Feb 2002 09:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GHOb4R013859 for ipng-dist; Sat, 16 Feb 2002 09:24:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GHOYKL013852 for ; Sat, 16 Feb 2002 09:24:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28347 for ; Sat, 16 Feb 2002 09:24:36 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15501 for ; Sat, 16 Feb 2002 10:24:36 -0700 (MST) Received: from lutchann by marduk.litech.org with local (Exim 3.22 #1) id 16c8Zf-000382-00 for ipng@sunroof.eng.sun.com; Sat, 16 Feb 2002 12:24:35 -0500 Date: Sat, 16 Feb 2002 12:24:35 -0500 From: Nathan Lutchansky To: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses Message-ID: <20020216122435.A474@litech.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable IMO, there are two separate scenarios in which some sort of prefix=20 delegation needs to be used: 1) A router establishes a point-to-point connection to a provider. 2) A new router is connected to a site's backbone link. =46rom Brian Haberman's comments at the interim meeting, it seemed that APD= =20 was designed for scenario (2), providing a means to "grow a network" (his= =20 words) without need for manual configuration. However, scenario (1) seems much more common, and indeed was the origin of= =20 this thread. Small IPv6 sites are inevitably connected to the 6bone with= =20 either a p-t-p tunnel or PPP, and there is no good reason we shouldn't=20 have some kind of mechanism to autoconfigure the border routers at these=20 sites. A draft by Itojun (draft-itojun-ipv6-dialup-requirement-02.txt)=20 describes some of the mechanisms that could be used for configuration, but= =20 makes no recommendations. Instead of using a stateful protocol like DHCPv6 or APD to configure customer sites, perhaps it would be best to use router advertisements on the p-t-p link. This was one of the more popular candidates for dialup configuration during Itojun's presentation in Seattle (the other popular candidate was APD). Instead of overloading the Prefix Information option, however, we could add an additional option to the router advertisement messages, "Delegated Prefix". This option could only be used on p-t-p links, of course. This technique would be lightweight, would be easy to implement for both the ISP and client sides, and would provide all the functionality needed for 90% of sites. -Nathan --=20 +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8bpXTTviDkW8mhycRAl5GAKCvq8eH5eAWK1wGqCw7ZT1S92ZMAwCeO0kB O/SZNXeZU8ri5VxyZSQMN7k= =VQ6O -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 17 10:53:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HIrwKL015912 for ; Sun, 17 Feb 2002 10:53:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HIrwdK015911 for ipng-dist; Sun, 17 Feb 2002 10:53:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HIrtKL015904 for ; Sun, 17 Feb 2002 10:53:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29299 for ; Sun, 17 Feb 2002 10:53:57 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05937 for ; Sun, 17 Feb 2002 10:53:56 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HIruh09562 for ; Sun, 17 Feb 2002 10:53:56 -0800 (PST) Date: Sun, 17 Feb 2002 13:53:55 -0500 (EST) From: Ralph Droms To: Subject: RE: PPP and Global Addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have to ask - because I've never heard it raised as an issue outside this mailing list - has anyone ever heard a *network administrator* or other customer of IETF protocols say that "configuring routers with what is titled a host specific protocol will create more confusion than it is worth." If the name is truly a problem, I'm happy to follow up on the suggestion that we rename DHCP to "Dynamic Node Configuration Protocol" or "Dynamic Site Configuration Protocol" or "Yet Another Configuration Protocol". I'm having a hard time believing we're making technical decisions about protocol design based on the *name* of the protocols involved. Sheesh. BTW, just to review some ancient history, I added the infamous sentence "DHCP is not intended for use in configuring routers." (originally in RFC1531 and carried forward to RFC1541 and RFC2131) to limit the scope of the problem we were trying to solve. That was (literally) 10 years ago. Maybe it's OK now to reconsider that constraint. The sentence is *not* included in draft-ietf-dhc-dhcpv6-23.txt. - Ralph On Sat, 16 Feb 2002, Pekka Savola wrote: > On Fri, 15 Feb 2002, Tony Hain wrote: > > Ole Troan wrote: > > > ... > > > would you be happier if we renamed it to SNCP (Simple Node > > > Configuration Protocol)? :-) > > > > Actually, yes. Routers are not hosts, so configuring routers with what > > is titled a host specific protocol will create more confusion than it is > > worth. > > Just a point: the value of router/host toggle is interface-specific. This > was dicussed, hmm, probably around 6-9 months ago here in the context of > RFC2461. > > I also think DHCP and what not should not be used for router > configuration. > > > > > for me this boils down to picking a packet format on the wire. DHCP > > > offers a more flexible option format, is more extensible, has a > > > defined relay mechanism, offers a Reconfigure mechanism so it is > > > possible to poke the requesting router. I have no problem with using > > > ICMP PD, my point is that as we move along it is going to look awfully > > > much like DHCP. > > > > If we are going to need a stateful protocol tied to an authentication > > system, using the wire format and option richness of a widely deployed > > protocol makes more sense than inventing a new one. At the same time, > > going that route requires a serious look at the defined options to find > > any potential security holes that may exist because there was a > > historical assumption that the option applied to an end system not a > > router. If a router requesting one of the existing options opens a big > > hole, we really do need a new protocol. > > > > Tony > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 17 12:56:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HKuSKL016131 for ; Sun, 17 Feb 2002 12:56:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HKuSWA016130 for ipng-dist; Sun, 17 Feb 2002 12:56:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HKuOKL016123 for ; Sun, 17 Feb 2002 12:56:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03174 for ; Sun, 17 Feb 2002 12:56:27 -0800 (PST) Received: from uhura.techfuturum.landskrona.se ([193.12.222.246]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25293 for ; Sun, 17 Feb 2002 13:56:26 -0700 (MST) Received: from win2k ([193.12.113.174]) by uhura.techfuturum.landskrona.se with Microsoft SMTPSVC(5.0.2195.2966); Sun, 17 Feb 2002 21:56:45 +0100 Message-ID: <001801c1b7f5$cc1bf7a0$0a80a8c0@win2k> From: =?iso-8859-1?Q?Torbj=F6rn_Samuelsson?= To: Subject: When is IPv6 Date: Sun, 17 Feb 2002 21:58:04 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C1B7FE.2CC2BAA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 17 Feb 2002 20:56:45.0771 (UTC) FILETIME=[9C2649B0:01C1B7F5] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1B7FE.2CC2BAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 =20 I'm currently working on projects that are going to evaluate the = implementation of IPv6 in a local MAN in Sweden; I'm doing this as an = exam project fore my school. I'm leaveing school in about 3 months I'm = glad to say. =20 However my question is when is the realistic time to expect IPv6 to be = out there and accessible fore the "common" client? This is naturally = very hard to say but I only wish to her your opinions and don't expect = it to be the absolute truth.=20 =20 I have heard other people that believe it will be the year of 2005 that = is the big year for IPv6. Is this what you believe to be realistic or = not. =20 Best regards Torbj=F6rn ------=_NextPart_000_0015_01C1B7FE.2CC2BAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
I’m currently = working on=20 projects that are going to evaluate the implementation of IPv6 in a = local MAN in=20 Sweden; I’m doing this as an exam project fore my school. I'm = leaveing school in=20 about 3 months I'm glad to say.
 
However my question is when = is the=20 realistic time to expect IPv6 to be out there and accessible fore the = "common"=20 client? This is naturally very hard to say but I only wish to her your = opinions=20 and don’t expect it to be the absolute truth.
 
I have = heard other=20 people that believe it will be the year of 2005 that is the big year for = IPv6.=20 Is this what you believe to be realistic or not.
 
Best = regards=20 Torbj=F6rn
 
------=_NextPart_000_0015_01C1B7FE.2CC2BAA0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 18 00:08:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I88NKL016949 for ; Mon, 18 Feb 2002 00:08:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1I88NMO016948 for ipng-dist; Mon, 18 Feb 2002 00:08:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I88JKL016941 for ; Mon, 18 Feb 2002 00:08:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14554 for ; Mon, 18 Feb 2002 00:08:20 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15355 for ; Mon, 18 Feb 2002 01:08:19 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:55a4:dc0e:4efc:e80]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1I889o50584; Mon, 18 Feb 2002 17:08:09 +0900 (JST) Date: Mon, 18 Feb 2002 17:08:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <200202141857.KAA02715@feller.mentat.com> References: <200202141857.KAA02715@feller.mentat.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 88 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (sorry for the delayed response. I'm just back from a short vacation.) >>>>> On Thu, 14 Feb 2002 10:57:45 -0800 (PST), >>>>> Tim Hartrick said: >> I agree. If it is really easy to deal with the send side as you said, >> it would be the best candidate (so I'd like to know the details). > I had missed the change in receive side semantics. More badness. Why Let me confirm, did you say the change in the receive side was "more bad"? I don't get the relationship between the change in the receive side and the rest of your message... > can't the order of the setsockopt calls establish the order of the > routing header and the destination options? I don't see why it isn't that > simple except in the case where ancillary data and sticky options are > intermingled. I don't think it is a good idea to assume the relationship of two separate (and different) socket options and make application programmers take care of the ordering. This approach is in fact essentially the same thing as IPV6_RTHDRDSTOPTS with additional confusion; for example, it is not clear on what happens when we remove a routing header after specifying a couple of destination options headers. It is also unclear on how to remove a particular destination options header after specifying a couple of ones.... I'd rather prefer IPV6_RTHDRDSTOPTS to this approach. > This is another reason why it was better to allow ancillary data to override > ALL sticky options rather than just like sticky options. This change has > substantially complicated the implementation for little benefit. Oh well. > Just put this mess to bed. I still strongly believe that the current overriding rule is more natural for application programmers with the fact we've separated sticky options as a separate set of single socket options. Here is a recap of an old message of mine (in a private discussion). I think this is still reasonable enough, and do not think the result is "little benefit": Anyway, first I thought that the previous behavior was natural. On the second thought, however, I changed my mind. The previous overriding scheme is reasonable in RFC2292, because we can only specify a "set" of options in a single sticky option; IPV6_PKTOPTIONS. But, in rfc2292bis, we have separated each option so that it could be specified as a single sticky option. Additionally, we have much more ancillary data items/sticky options than in RFC2292, and there is an "ancillary-only" option (IPV6_REACHCONF). Perhaps due to all of these points, some applications use both an ancillary data item and a sticky option expecting that both of them can be enabled at the same time. BIND 9 is an example; it uses IPV6_USE_MIN_MTU as a sticky option for the UDP socket as well as IPV6_PKTINFO ancillary data items to specify the source address. If the underlying kernel strictly follows rfc2292bis-02, the IPV6_USE_MIN_MTU sticky option would be disabled. Of course, we could say that "it's a bug and the application should be corrected." However, I think such a usage of BIND 9 is quite natural to application programmers, and what should be changed is the API specification. === Through the discussion so far, my feeling on this issue is that we should just go with the current specification. It's true that IPV6_RTHDRDSTOPTS is useless at least for now and will probably be in the foreseeable future. However, the current spec is clear enough and is consistent with the policy of adopting the "recommended" order described in RFC 2460 as a limitation within this particular API spec. As everyone admits (I believe so), we do not need a "perfect" specification; the most important thing is to provide application programmers with a uniform API that can cover today (and the foreseeable future)'s typical applications. We should be able to live with the spec as long as it is clear enough. If necessary, we can add a note that there is no use of IPV6_RTHDRDSTOPTS as of writing the API and that applications will only need IPV6_DSTOPTS in most cases. Can we agree with this? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 18 01:24:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I9OIKL017175 for ; Mon, 18 Feb 2002 01:24:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1I9OIF2017174 for ipng-dist; Mon, 18 Feb 2002 01:24:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I9OFKL017167 for ; Mon, 18 Feb 2002 01:24:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26931 for ; Mon, 18 Feb 2002 01:24:15 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08150 for ; Mon, 18 Feb 2002 02:23:22 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1I7BxT02065; Mon, 18 Feb 2002 14:12:00 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Tony Hain , Ole Troan , Francis Dupont , NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Configuring Routers In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Feb 2002 14:11:59 +0700 Message-ID: <2063.1014016319@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I changed the Subject line...] Date: Sat, 16 Feb 2002 17:50:18 +0200 (EET) From: Pekka Savola Message-ID: | I also think DHCP and what not should not be used for router | configuration. I'm trying to understand what is lurking in the background here, and I think I'm failing. That is, I have no idea at all what the objections are, the oft repeated "I don't think ... should be used" (I picked just one example above) means nothing - there's no explanation for what the problem might be. It could just be that people believe that the only way to ever configure a router is manually, and that any protocol to automate the process is necessarily flawed. If so, I'd like to understand why, but I think I'd tend to ignore that sentiment - other than to make sure that implementations keep on making it possible to manually configure, so that people who believe this don't have the rug yanked out from under them (and in certain particular circumstances, I think this probably includes all of us). Or, it could be that there's something in particular about DHCP that makes it unsuitable - its lack of authentication for example (is that still true of DHCPv6? One day I must go read that draft...) - or that if you're going to have to configure authentication manually, you may as well just config the addresses (etc) instead. So, could all those objecting please say exactly what it is that is the problem, and not just repeat the "I don't like it" comments? Then perhaps it will be possible for others to refute the alleged problems, or to learn about a defect they weren't aware of, and fix the protocol (or even invent a new protocol, if the existing possibilities are beyond fixing). I find it a bit difficult to believe though that there's anything so special about a router that makes it impossible to configure using a protocol ... after all, we have (most of us) been using TELNET to configure routers for many many years now, and while there's usually a human on the client end of the telnet connection, there doesn't need to be - a script can configure routers just as easily (and I've seen scripts around for this kind of purpose). These days routers even offer http servers as a config device, and automation to talk to http servers is as comon as dirt. And then, there are also routers that simply invent their own configuration if they can figure out some data somehow. So, it is pretty clear there's a demand for configuring routers some way other than manually, it is also pretty clear that it is possible. If it can be done and people want it, it sounds to me as if a standardised method (as an optional extra, not as the only way) is likely to be an improvement. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 06:16:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JEGuKL020047 for ; Tue, 19 Feb 2002 06:16:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JEGuvx020046 for ipng-dist; Tue, 19 Feb 2002 06:16:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JEGrKL020039 for ; Tue, 19 Feb 2002 06:16:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26721 for ; Tue, 19 Feb 2002 06:16:55 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA27313 for ; Tue, 19 Feb 2002 06:16:49 -0800 (PST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4FA4YK>; Tue, 19 Feb 2002 14:42:52 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E3D538@lat3721.rd.francetelecom.fr> From: BINET David FTRD/DMI/CAE To: "'Robert Elz'" , Pekka Savola Cc: Tony Hain , Ole Troan , Francis Dupont , NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: RE: Configuring Routers Date: Tue, 19 Feb 2002 14:42:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-41c6e4d5-246b-11d6-b1e5-00508b69ab48" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-41c6e4d5-246b-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B94B.57624BB0" ------_=_NextPart_001_01C1B94B.57624BB0 Content-Type: text/plain > | I also think DHCP and what not should not be used for router > | configuration. > > I'm trying to understand what is lurking in the background here, and > I think I'm failing. That is, I have no idea at all what > the objections > are, the oft repeated "I don't think ... should be used" (I > picked just > one example above) means nothing - there's no explanation for what the > problem might be. It was the feeling I had when I sent my first e-mail. And there was no explanation at this point in time except a problem of name of the protocol. > > It could just be that people believe that the only way to > ever configure > a router is manually, and that any protocol to automate the process is > necessarily flawed. If so, I'd like to understand why, but > I think I'd > tend to ignore that sentiment - other than to make sure that > implementations > keep on making it possible to manually configure, so that people who > believe this don't have the rug yanked out from under them > (and in certain > particular circumstances, I think this probably includes all of us). There is need for an automatic configuration process for routers in some circumstances and a point to point connection to a provider is one of these circumstances. It seems that the use of router advertisement is the best candidate for such need, according to the majority of persons in the IPv6 community, if I have understood the previous mails. Nevertheless, I think that DHCPv6 represents a good alternative, despite the fact that it is certainly not so lightweight than RA. Except the new options proposed by Ole and Ralph, I think that other options provided by the DHCPv6 protocol can be used for the configuration of the Equipment (which can be more than a router) in the customer site. The reconfigure message in the DHCPv6 protocol is also an important mechanism for such context. David > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1B94B.57624BB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Configuring Routers

>   | I also think DHCP and what not = should not be used for router
>   | configuration.
>
> I'm trying to understand what is lurking in the = background here, and
> I think I'm failing.   That is, I = have no idea at all what
> the objections
> are, the oft repeated "I don't think ... = should be used" (I
> picked just
> one example above) means nothing - there's no = explanation for what the
> problem might be.

It was the feeling I had when I sent my first e-mail. = And there was no explanation at this point in time except a problem of = name of the protocol.

>
> It could just be that people believe that the = only way to
> ever configure
> a router is manually, and that any protocol to = automate the process is
> necessarily flawed.   If so, I'd like = to understand why, but
> I think I'd
> tend to ignore that sentiment - other than to = make sure that
> implementations
> keep on making it possible to manually = configure, so that people who
> believe this don't have the rug yanked out from = under them
> (and in certain
> particular circumstances, I think this probably = includes all of us).

There is need for an automatic configuration process = for routers in some circumstances and a point to point connection to a = provider is one of these circumstances. It seems that the use of router = advertisement is the best candidate for such need, according to the = majority of persons in the IPv6 community, if I have understood the = previous mails. Nevertheless, I think that DHCPv6 represents a good = alternative, despite the fact that it is certainly not so lightweight = than RA. Except the new options proposed by Ole and Ralph, I think that = other options provided by the DHCPv6 protocol can be used for the = configuration of the Equipment (which can be more than a router) in the = customer site. The reconfigure message in the DHCPv6 protocol is also = an important mechanism for such context.   

David
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1B94B.57624BB0-- ------=_NextPartTM-000-41c6e4d5-246b-11d6-b1e5-00508b69ab48-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 13:43:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JLhoKL021335 for ; Tue, 19 Feb 2002 13:43:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JLhoK9021334 for ipng-dist; Tue, 19 Feb 2002 13:43:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JLhlKL021327 for ; Tue, 19 Feb 2002 13:43:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00204 for ; Tue, 19 Feb 2002 13:43:50 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA19424 for ; Tue, 19 Feb 2002 14:43:49 -0700 (MST) Received: (qmail 26314 invoked from network); 19 Feb 2002 21:43:47 -0000 Received: from pd950f82e.dip.t-dialin.net (HELO ??) (217.80.248.46) by mail.bieringer.de with SMTP; 19 Feb 2002 21:43:47 -0000 Date: Tue, 19 Feb 2002 22:44:03 +0100 From: Peter Bieringer To: Maillist IPng Subject: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries Message-ID: <60380000.1014155043@localhost> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, during implementing bit-string label support in "ipv6calc" I run (for me) into a problem and found no example. Every example shows prefix lengths in 4 bit boundaries :-( Printing prefices: 1) "Standard": 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/64 -> \[x3ffeffff01234567/64] 2) Now what about: 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/63 -> \[x3ffeffff01234566/63] ? or 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/65 -> \[x3ffeffff012345678/65] ? Is this ok, keeping most significant bits aligned? Printing suffices: 3) "Standard": 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/64 -> \[x89abcdef00112233/64] 4) Now what about: 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/63 -> \[x189abcdef00112233/65] ? or 3ffe:ffff:0123:4567:89ab:cdef:0011:2233/65 -> \[x09abcdef00112233/63] Is this ok, keeping now least significant bits aligned? If both to "yes", this isn't a unique representation because who decides when to use which bits. Major question: from which position are the bits are counted and displayed aligned? >From the left one or from the right one? Has anyone a definition or examples available? Looks like either suffices or prefixes have to be shifted bitwise in displaying resulting in not easy recogniced values afterwards. RFC 2874 doesn't really help me, perhaps because of my less English knowlegde... Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 15:13:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JNDvKL021546 for ; Tue, 19 Feb 2002 15:13:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JNDurI021545 for ipng-dist; Tue, 19 Feb 2002 15:13:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JNDrKL021538 for ; Tue, 19 Feb 2002 15:13:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00133 for ; Tue, 19 Feb 2002 15:13:55 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12599 for ; Tue, 19 Feb 2002 16:13:50 -0700 (MST) Received: from lutchann by marduk.litech.org with local (Exim 3.22 #1) id 16dJRL-0000HK-00; Tue, 19 Feb 2002 18:12:51 -0500 Date: Tue, 19 Feb 2002 18:12:51 -0500 From: Nathan Lutchansky To: haberman@lorien.sc.innovationslab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses Message-ID: <20020219181251.A28433@litech.org> References: <20020216122435.A474@litech.org> <3C710A95.44E59267@innovationslab.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C710A95.44E59267@innovationslab.net>; from haberman@innovationslab.net on Mon, Feb 18, 2002 at 09:07:17AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2002 at 09:07:17AM -0500, Brian Haberman wrote: > Since I wasn't at the interim meeting, I am pretty sure that I > did not make that comment. :) I'm sorry about that; it must have been Jim Martin since I'm quite sure it= =20 was one of the authors of the draft. I apologize for putting words in=20 your mouth, but at least I am not misinterpreting your intentions... > However, the work that has been done > on automatic prefix delegation is geared mainly towards your point > (1) below. In fact, I am in the process of revving the PD draft to > incorporate comments and suggestions from people who want to use > PD for CPE-to-ISP connections. A point was made at the interim meeting (by Tony Hain, I believe, although I trust my memory less now) that it would be prudent of us to ensure that the ISP connection procedure for single hosts vs. routers is identical. =20 Otherwise, providers will be much more likely to charge extra to connect a router, which leads to IPv6 NAT, (which leads to anger, which leads to hate,) which is definitely not what we want to be encouraging. As I see it now, using APD for prefix delegation would require routers to start an APD transaction -- something hosts wouldn't need to do. Personally, I am much more likely to endorse a passive mechanism (router advertisements) than an active mechanism (APD, router renumbering, DHCP), provided there is no significant disadvantage. Over the weekend I wrote a draft to define a new option for rtadv messages to delegate a prefix over a p-t-p link. I'm trying to keep it as simple and easy to implement as possible, since any setup that's remotely complicated should use router renumbering (if that ever gets standardized). My draft didn't submitted until today, though, since my DSL has been down a day or so... -Nathan --=20 +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ctvyTviDkW8mhycRAlmXAJsHx4EumthlRVCHl6RFLGJbW51KqACdHPpA iOtSmQ/NMjPCLZLrNWvCJOk= =90Xs -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 17:27:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1RiKL022097 for ; Tue, 19 Feb 2002 17:27:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K1Riv3022096 for ipng-dist; Tue, 19 Feb 2002 17:27:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1RfKL022089 for ; Tue, 19 Feb 2002 17:27:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12751 for ; Tue, 19 Feb 2002 17:27:44 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17312 for ; Tue, 19 Feb 2002 18:27:43 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA09600; Tue, 19 Feb 2002 17:27:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1K1Rg209887; Tue, 19 Feb 2002 17:27:42 -0800 X-mProtect:  Tue, 19 Feb 2002 17:27:42 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgfkZlV; Tue, 19 Feb 2002 17:27:39 PST Message-Id: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Feb 2002 17:26:46 -0800 To: Robert Elz From: Bob Hinden Subject: Re: Configuring Routers Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2063.1014016319@brandenburg.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk KRE, >It could just be that people believe that the only way to ever configure >a router is manually, and that any protocol to automate the process is >necessarily flawed. If so, I'd like to understand why, but I think I'd >tend to ignore that sentiment - other than to make sure that implementations >keep on making it possible to manually configure, so that people who >believe this don't have the rug yanked out from under them (and in certain >particular circumstances, I think this probably includes all of us). It's a good question. My suspicion is that because much of many routers configuration is specific each router, that it doesn't matter to much if it is entered directly into the router with a CLI or web interface, or equivalently typed into some sort of protocol server. Also much of a routers configuration is not amenable to dynamic creation. Unlike hosts there isn't too much labor saving in having a DRCP. Where a protocol might be needed, people have gotten around the lack of a protocol by creating CLI files with an editor and pushing them to the router. The editor makes it easy to make the common parts the same and customize the rest. I think there can even be includes in many vendors CLI files. There are cases (e.g., sub routers at the end of DSL, etc.) where the configurations are very similar, where some sort of DRCP might be useful. I think DHCPv4 is used for this today when the stub router also includes a NAT. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 17:41:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1f7KL022222 for ; Tue, 19 Feb 2002 17:41:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K1f77R022221 for ipng-dist; Tue, 19 Feb 2002 17:41:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1f4KL022214 for ; Tue, 19 Feb 2002 17:41:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14973 for ; Tue, 19 Feb 2002 17:41:06 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26652 for ; Tue, 19 Feb 2002 17:41:05 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dLka-000DMU-00; Tue, 19 Feb 2002 17:40:52 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Configuring Routers References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> Message-Id: Date: Tue, 19 Feb 2002 17:40:52 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk there are isps where a human never types at a router (except to debug) and all configuration is programatically generated from enterprise and customer data entered by folk from sales to provisioning to address admin through sexy gui interfaces. the canonic configuration is the data in the data- base, and the classic phrase "the network is the data-base of record" is anathema. these configuration generation systems have 'back ends' (excuse the compiler term) for many vendors' so-called configuration languages, and the router brand, model, and sw version are but more parameters in the data-base. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 17:52:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1qsKL022330 for ; Tue, 19 Feb 2002 17:52:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K1qsMb022329 for ipng-dist; Tue, 19 Feb 2002 17:52:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K1qpKL022322 for ; Tue, 19 Feb 2002 17:52:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02969 for ; Tue, 19 Feb 2002 17:52:52 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28602 for ; Tue, 19 Feb 2002 18:52:51 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA02198; Wed, 20 Feb 2002 01:52:46 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Randy Bush Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Configuring Routers References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> From: Ole Troan Date: Wed, 20 Feb 2002 01:52:46 +0000 In-Reply-To: (Randy Bush's message of "Tue, 19 Feb 2002 17:40:52 -0800") Message-ID: <7t5it8s6hsh.fsf@mrwint.cisco.com> Lines: 16 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > there are isps where a human never types at a router (except to debug) and > all configuration is programatically generated from enterprise and customer > data entered by folk from sales to provisioning to address admin through > sexy gui interfaces. the canonic configuration is the data in the data- > base, and the classic phrase "the network is the data-base of record" is > anathema. > > these configuration generation systems have 'back ends' (excuse the compiler > term) for many vendors' so-called configuration languages, and the router > brand, model, and sw version are but more parameters in the data-base. that doesn't cross administrative boundaries very well, and doesn't help a provider to assign prefixes to its customers. kudos for the system though. :) /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 19 18:01:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K218KL022387 for ; Tue, 19 Feb 2002 18:01:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K218dO022386 for ipng-dist; Tue, 19 Feb 2002 18:01:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K215KL022379 for ; Tue, 19 Feb 2002 18:01:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04901 for ; Tue, 19 Feb 2002 18:01:07 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02841 for ; Tue, 19 Feb 2002 18:01:06 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dM3t-000Ht2-00; Tue, 19 Feb 2002 18:00:49 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ole Troan Cc: ipng@sunroof.eng.sun.com Subject: Re: Configuring Routers References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> <7t5it8s6hsh.fsf@mrwint.cisco.com> Message-Id: Date: Tue, 19 Feb 2002 18:00:49 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > that doesn't cross administrative boundaries very well crosses some, not others > and doesn't help a provider to assign prefixes to its customers it can. that would rely on o the system tracking what is allocated to the pop and aggregation router pool o sales/provisioning being able to specify how much the customer needs of course, in v6, this will all be easier, as space is infinite, we can allocate infinite space to each customer :-) folk don't really think the survivors will be still scrabbling at the coal face with their bare fingernails in five years, do they? it just does not scale. isps which do not scale get bought by telephants who do not think, and they make great bed-fellows. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 00:05:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K85WKL022930 for ; Wed, 20 Feb 2002 00:05:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K85WP7022929 for ipng-dist; Wed, 20 Feb 2002 00:05:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K85SKL022922 for ; Wed, 20 Feb 2002 00:05:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29377 for ; Wed, 20 Feb 2002 00:05:29 -0800 (PST) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29269 for ; Wed, 20 Feb 2002 00:05:29 -0800 (PST) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 57B7022E; Wed, 20 Feb 2002 00:05:28 -0800 (PST) Date: Wed, 20 Feb 2002 00:05:27 -0800 From: David Terrell To: Peter Bieringer Cc: Maillist IPng Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries Message-ID: <20020220000527.C9645@pianosa.catch22.org> Reply-To: David Terrell References: <60380000.1014155043@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <60380000.1014155043@localhost>; from pb@bieringer.de on Tue, Feb 19, 2002 at 10:44:03PM +0100 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:04AM up 5 days, 8:12, 25 users, load averages: 1.67, 1.70, 1.60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Feb 19, 2002 at 10:44:03PM +0100, Peter Bieringer wrote: > Hi, > > during implementing bit-string label support in "ipv6calc" I run (for > me) into a problem and found no example. Save your energy, bit-strings are being deprecated in the ip6.arpa tree. -- David Terrell | Q. Is C an acronym? dbt@meat.net | A. Yes, it stands for ``C''. It's another Nebcorp Prime Minister | of those funky recursive acronyms. http://wwn.nebcorp.com/ | - "Infrequently asked questions in comp.lang.c" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 00:16:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K8GgKL022967 for ; Wed, 20 Feb 2002 00:16:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K8Ggjl022966 for ipng-dist; Wed, 20 Feb 2002 00:16:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K8GcKL022959 for ; Wed, 20 Feb 2002 00:16:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09261 for ; Wed, 20 Feb 2002 00:15:55 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA10553 for ; Wed, 20 Feb 2002 01:15:54 -0700 (MST) Received: (qmail 9472 invoked from network); 20 Feb 2002 08:15:53 -0000 Received: from pd950f94e.dip.t-dialin.net (HELO ??) (217.80.249.78) by mail.bieringer.de with SMTP; 20 Feb 2002 08:15:53 -0000 Date: Wed, 20 Feb 2002 09:16:10 +0100 From: Peter Bieringer To: David Terrell cc: Maillist IPng Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries Message-ID: <44900000.1014192970@localhost> In-Reply-To: <20020220000527.C9645@pianosa.catch22.org> References: <60380000.1014155043@localhost> <20020220000527.C9645@pianosa.catch22.org> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Wednesday, February 20, 2002 12:05:27 AM -0800 David Terrell wrote: > On Tue, Feb 19, 2002 at 10:44:03PM +0100, Peter Bieringer wrote: >> Hi, >> >> during implementing bit-string label support in "ipv6calc" I run >> (for me) into a problem and found no example. > > Save your energy, bit-strings are being deprecated in the ip6.arpa > tree. Is this an official statement? Who tell this all very modern resolvers... BTW: looks like the same problem occurs in the forward chaining using A6. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 01:26:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9QfKL023050 for ; Wed, 20 Feb 2002 01:26:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K9QfvJ023049 for ipng-dist; Wed, 20 Feb 2002 01:26:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9QcKL023042 for ; Wed, 20 Feb 2002 01:26:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23536 for ; Wed, 20 Feb 2002 01:26:36 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03545 for ; Wed, 20 Feb 2002 02:26:35 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1K9QLt22376; Wed, 20 Feb 2002 11:26:21 +0200 Date: Wed, 20 Feb 2002 11:26:21 +0200 (EET) From: Pekka Savola To: Peter Bieringer cc: David Terrell , Maillist IPng Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries In-Reply-To: <44900000.1014192970@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Feb 2002, Peter Bieringer wrote: > --On Wednesday, February 20, 2002 12:05:27 AM -0800 David Terrell > wrote: > > > On Tue, Feb 19, 2002 at 10:44:03PM +0100, Peter Bieringer wrote: > >> Hi, > >> > >> during implementing bit-string label support in "ipv6calc" I run > >> (for me) into a problem and found no example. > > > > Save your energy, bit-strings are being deprecated in the ip6.arpa > > tree. > > Is this an official statement? Who tell this all very modern > resolvers... There are no official statements, but you may want to look at: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-00.txt or minutes from Dnsext/ngtrans joing meeting in IETF51 in London. No resolvers as such (used by default in operating systems) that I know of implement A6/DNAME; BIND9 lwres and friends are the only ones I think. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 01:29:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9TwKL023067 for ; Wed, 20 Feb 2002 01:29:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K9Tw50023066 for ipng-dist; Wed, 20 Feb 2002 01:29:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9TtKL023059 for ; Wed, 20 Feb 2002 01:29:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00119 for ; Wed, 20 Feb 2002 01:29:52 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07266 for ; Wed, 20 Feb 2002 01:29:45 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1K9UO601901; Wed, 20 Feb 2002 16:30:26 +0700 (ICT) From: Robert Elz To: Peter Bieringer cc: David Terrell , Maillist IPng Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries In-Reply-To: <44900000.1014192970@localhost> References: <44900000.1014192970@localhost> <60380000.1014155043@localhost> <20020220000527.C9645@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Feb 2002 16:30:24 +0700 Message-ID: <1899.1014197424@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 20 Feb 2002 09:16:10 +0100 From: Peter Bieringer Message-ID: <44900000.1014192970@localhost> | BTW: looks like the same problem occurs in the forward chaining using | A6. I'm not sure if there's a problem with alignment in bitstring (problem meaning perhaps unusual values needing to be generated), but there isn't in A6 - the address part of an A6 is always the least significant N (128 - prefix len field of A6 record) bits of the address, and the least significant bit of that is always the least significant possible bit of the value - so the alignment used in the A6 record, and the natural alignment of the address are always the same (ie: some bits may be cleared, or ignored, but they're never shifted around). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 01:35:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9ZYKL023086 for ; Wed, 20 Feb 2002 01:35:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K9ZYnU023085 for ipng-dist; Wed, 20 Feb 2002 01:35:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K9ZVKL023078 for ; Wed, 20 Feb 2002 01:35:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10590 for ; Wed, 20 Feb 2002 01:35:28 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09427 for ; Wed, 20 Feb 2002 01:35:27 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1K9XSc22427; Wed, 20 Feb 2002 11:33:28 +0200 Date: Wed, 20 Feb 2002 11:33:27 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Tony Hain , Ole Troan , Francis Dupont , NOISETTE Yoann FTRD/DMI/CAE , "'Yamasaki Toshi'" , Lilian Fernandes , , Subject: Re: Configuring Routers In-Reply-To: <2063.1014016319@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 18 Feb 2002, Robert Elz wrote: > It could just be that people believe that the only way to ever configure > a router is manually, and that any protocol to automate the process is > necessarily flawed. If so, I'd like to understand why, but I think I'd > tend to ignore that sentiment - other than to make sure that implementations > keep on making it possible to manually configure, so that people who > believe this don't have the rug yanked out from under them (and in certain > particular circumstances, I think this probably includes all of us). In my opinion, DHCP was not designed, from the start, to configure routers. Now, as an afterthough, capabilities are added to do just that. My worry is that some of the basic assumptions of DHCP architecture do not necessarily fit well into the new requirements of configuring routers. >From an operational point-of-view, I would not like have automatic configuration mechanisms (apart from, possibly, NTP/DNS/... settings) for the important routers. However, to make renumbering even remotely possible, I don't see a problem, as such, with configuring very simple routers (don't run routing protocols at all, no access-lists or acl's dynamically created, etc.) like DSL/Cable boxes via some mechanism. I think that would only be sensible. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 02:58:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KAw6KL023166 for ; Wed, 20 Feb 2002 02:58:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KAw6pr023165 for ipng-dist; Wed, 20 Feb 2002 02:58:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KAw3KL023158 for ; Wed, 20 Feb 2002 02:58:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18740 for ; Wed, 20 Feb 2002 02:58:05 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03274 for ; Wed, 20 Feb 2002 03:58:04 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1KAuXk07881; Wed, 20 Feb 2002 11:56:36 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA19882; Wed, 20 Feb 2002 11:56:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1KAuWg43606; Wed, 20 Feb 2002 11:56:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202201056.g1KAuWg43606@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Nathan Lutchansky cc: haberman@lorien.sc.innovationslab.net, ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Tue, 19 Feb 2002 18:12:51 EST. <20020219181251.A28433@litech.org> Date: Wed, 20 Feb 2002 11:56:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A point was made at the interim meeting (by Tony Hain, I believe, although I trust my memory less now) that it would be prudent of us to ensure that the ISP connection procedure for single hosts vs. routers is identical. Otherwise, providers will be much more likely to charge extra to connect a router, which leads to IPv6 NAT, (which leads to anger, which leads to hate,) which is definitely not what we want to be encouraging. => I understand the problem but I am afraid this is not possible with the current way to deal with single hosts, for instance with a single host the PPP link has a /64 global prefix and with a router the PPP link has only link-local addresses. The obvious solution is to use the mechanism for the router case in the single host case too, but this mechanism is not fully specified and not yet implemented, at the contrary the current mechanism for single hosts is just plain RFC 2462. Regards Francis.Dupont@enst-bretagne.fr PS: the conclusion is we should specify/finish/implement/deploy router mechanisms ASAP, at least before IPv6 dialups become common. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 06:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KEmWKL023321 for ; Wed, 20 Feb 2002 06:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KEmW9S023320 for ipng-dist; Wed, 20 Feb 2002 06:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KEmSKL023313 for ; Wed, 20 Feb 2002 06:48:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29051 for ; Wed, 20 Feb 2002 06:48:26 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03398 for ; Wed, 20 Feb 2002 07:48:24 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:bc64:975a:9aa7:395f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1KEmEo69955; Wed, 20 Feb 2002 23:48:14 +0900 (JST) Date: Wed, 20 Feb 2002 23:48:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <3C6ABB5D.20A2A1B4@zk3.dec.com> References: <200202121916.g1CJGAg05367@givry.rennes.enst-bretagne.fr> <3C6ABB5D.20A2A1B4@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Feb 2002 14:15:41 -0500, >>>>> Vladislav Yasevich said: >> >> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) >> >> > Do you mean the send() message should return an (immediate) error when >> > the packet is not fit in the outgoing link MTU? But, as Erik >> > explained in his reply to Vlad, we cannot always expect the immediate >> > error. I admit the spec is a bit complex, but the spec should be >> > generic enough (i.e. we cannot assume a particular type of OSes.) >> >> > => I've read Erik's answer but just try to explain the MTU stuff to >> > a common programmer... >> >> So, what do you want in this section? Are you requiring a change >> here? If so, please be more specific. > Would you agree on adding the text similar to Section 6.6 about an additional > error message on sendmsg(). The precendence is already set by Section 6.6, > but I don't have a very strong opinion on this. Okay, I'll add EMSGSIZE as an additional error to Section 11.2. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 07:08:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KF8gKL023428 for ; Wed, 20 Feb 2002 07:08:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KF8fVN023427 for ipng-dist; Wed, 20 Feb 2002 07:08:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KF8cKL023420 for ; Wed, 20 Feb 2002 07:08:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03332 for ; Wed, 20 Feb 2002 07:08:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00729 for ; Wed, 20 Feb 2002 08:08:36 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:bc64:975a:9aa7:395f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1KF8Yo70170 for ; Thu, 21 Feb 2002 00:08:34 +0900 (JST) Date: Thu, 21 Feb 2002 00:08:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: summary of necessary changes for rfc2292bis User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There seems to be no further arguments on the rfc2292bis draft. The followings are a summary of necessary changes to the latest (05) revision of the draft (as far as I understand): - 6.1: add a forward reference to Section 6.7 about the outgoing interface selection - 6.2: IPV6_PKTINFO should be forbidden for TCP - 9.2: make it more clear that the recommended header ordering (described in RFC2460) is just a limitation in this particular API. - 11.2: add EMSGSIZE as an additional error (like in Section 6.6) - 11.5: remove this section (about IPV6_REACHCONF) No other changes will be made in the next revision. In particular, - definitions for an ongoing stuff such as mobile IPv6 will not be included. - IPV6_RTHDRDSTOPTS will be kept. - the overriding rule for sticky options described in Section 4.2 will be unchanged. I'll soon make the changes above and submit the 06 revision of the draft. If I miss something, please point it out. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 07:33:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFX4KL023487 for ; Wed, 20 Feb 2002 07:33:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFX3QM023486 for ipng-dist; Wed, 20 Feb 2002 07:33:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFX0KL023479 for ; Wed, 20 Feb 2002 07:33:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22805 for ; Wed, 20 Feb 2002 07:33:02 -0800 (PST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21369 for ; Wed, 20 Feb 2002 08:33:01 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 79B0E840 for ; Wed, 20 Feb 2002 07:39:25 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id C0DA51960 for ; Wed, 20 Feb 2002 10:33:00 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1KFWxR25287; Wed, 20 Feb 2002 10:32:59 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id KAA0000077751; Wed, 20 Feb 2002 10:32:59 -0500 (EST) Message-ID: <3C73C1AB.F09CB83E@zk3.dec.com> Date: Wed, 20 Feb 2002 10:32:59 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of necessary changes for rfc2292bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya wrote: ... > - 6.2: IPV6_PKTINFO should be forbidden for TCP ... I guess I missed the discussion above the above bullet. I don't believe it should be explicitely forbidden. Specifying the outgoing interface may be a useful feature. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 07:47:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFlTKL023693 for ; Wed, 20 Feb 2002 07:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFlTOt023692 for ipng-dist; Wed, 20 Feb 2002 07:47:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFlPKL023685 for ; Wed, 20 Feb 2002 07:47:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24895 for ; Wed, 20 Feb 2002 07:47:27 -0800 (PST) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19522 for ; Wed, 20 Feb 2002 08:47:26 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 32DEE3E1D for ; Wed, 20 Feb 2002 09:47:26 -0600 (CST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 4097A18B8 for ; Wed, 20 Feb 2002 07:47:25 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1KFlNR28007; Wed, 20 Feb 2002 10:47:24 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id KAA0000077787; Wed, 20 Feb 2002 10:47:23 -0500 (EST) Message-ID: <3C73C50B.CB310BAE@compaq.com> Date: Wed, 20 Feb 2002 10:47:23 -0500 From: Vladislav Yasevich Reply-To: vlad@zk3.dec.com X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: IPNG Working Group Subject: test... please ignore Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich IPv6 Project Lead Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Tel: (603) 884-1079 Nashua, NH 03062 Fax: (435) 514-6884 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 07:50:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFotKL023734 for ; Wed, 20 Feb 2002 07:50:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFotlp023733 for ipng-dist; Wed, 20 Feb 2002 07:50:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFopKL023719 for ; Wed, 20 Feb 2002 07:50:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11593 for ; Wed, 20 Feb 2002 07:50:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21305 for ; Wed, 20 Feb 2002 08:50:52 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA10970; Wed, 20 Feb 2002 07:50:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1KFopc21018; Wed, 20 Feb 2002 07:50:51 -0800 X-mProtect:  Wed, 20 Feb 2002 07:50:51 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.64, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6Sab3O; Wed, 20 Feb 2002 07:50:48 PST Message-Id: <4.3.2.7.2.20020220074024.025f8808@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Feb 2002 07:49:52 -0800 To: Randy Bush From: Bob Hinden Subject: Re: Configuring Routers Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, At 05:40 PM 2/19/2002, Randy Bush wrote: >there are isps where a human never types at a router (except to debug) and >all configuration is programatically generated from enterprise and customer >data entered by folk from sales to provisioning to address admin through >sexy gui interfaces. the canonic configuration is the data in the data- >base, and the classic phrase "the network is the data-base of record" is >anathema. Interesting. Does this apply to both edge routers near the customer and the backbone-peering routers? Are these tools commercial products or are they developed by each isp? >these configuration generation systems have 'back ends' (excuse the compiler >term) for many vendors' so-called configuration languages, and the router >brand, model, and sw version are but more parameters in the data-base. To bring this back to the thread, do you think there is a need for a protocol here or are the current solutions adequate? It must be fun to keep these tools in sync with sw releases, differences in vendor capabilities, etc. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 08:03:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KG34KL023826 for ; Wed, 20 Feb 2002 08:03:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KG34ie023825 for ipng-dist; Wed, 20 Feb 2002 08:03:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KG31KL023818 for ; Wed, 20 Feb 2002 08:03:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26329 for ; Wed, 20 Feb 2002 08:03:03 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06697 for ; Wed, 20 Feb 2002 09:03:02 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dZCk-000Fxe-00; Wed, 20 Feb 2002 08:02:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Configuring Routers References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> <4.3.2.7.2.20020220074024.025f8808@mailhost.iprg.nokia.com> Message-Id: Date: Wed, 20 Feb 2002 08:02:50 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> there are isps where a human never types at a router (except to debug) and >> all configuration is programatically generated from enterprise and customer >> data entered by folk from sales to provisioning to address admin through >> sexy gui interfaces. the canonic configuration is the data in the data- >> base, and the classic phrase "the network is the data-base of record" is >> anathema. > Interesting. Does this apply to both edge routers near the customer and > the backbone-peering routers? Are these tools commercial products or are > they developed by each isp? one i know goes all the way to cpe. none are commercial, too small a market, too few large isps. so all commercial efforts i know failed. note that there are embarrassingly few of these systems. many isps do configure by hand, and some embarrassingly large ones. as the consequence of manual configuration is horrible cost/customer curves as things scale up, those that don't will die in the margin squeeze just as they're dying in long distance minutes today. sometimes, the goddess is just. > To bring this back to the thread, do you think there is a need for a > protocol here or are the current solutions adequate? It must be fun to > keep these tools in sync with sw releases, differences in vendor > capabilities, etc. job security for old hackers! :-) i suspect/hope that 20 years from now we will understand a lot more about infrastructure topology discovery and construction, accompanied by solid underlying theory, and will view this discussion as pretty primitive. of course, we have to live in today. but we should refrain from being cute or complex. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 08:26:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGQeKL023854 for ; Wed, 20 Feb 2002 08:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KGQeW4023853 for ipng-dist; Wed, 20 Feb 2002 08:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGQbKL023846 for ; Wed, 20 Feb 2002 08:26:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21074 for ; Wed, 20 Feb 2002 08:26:38 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19832 for ; Wed, 20 Feb 2002 09:26:37 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA12908; Wed, 20 Feb 2002 08:26:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1KGQaS25934; Wed, 20 Feb 2002 08:26:36 -0800 X-mProtect:  Wed, 20 Feb 2002 08:26:36 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.64, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZcJ5lC; Wed, 20 Feb 2002 08:26:33 PST Message-Id: <4.3.2.7.2.20020220082239.02e3af08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Feb 2002 08:25:01 -0800 To: Randy Bush From: Bob Hinden Subject: Re: Configuring Routers Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> <4.3.2.7.2.20020220074024.025f8808@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, >i suspect/hope that 20 years from now we will understand a lot more about >infrastructure topology discovery and construction, accompanied by solid >underlying theory, and will view this discussion as pretty primitive. of >course, we have to live in today. but we should refrain from being cute >or complex. I hope in 20 years we will understand a lot more about many things :-) Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 08:43:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGhSKL023941 for ; Wed, 20 Feb 2002 08:43:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KGhS4g023940 for ipng-dist; Wed, 20 Feb 2002 08:43:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGhPKL023933 for ; Wed, 20 Feb 2002 08:43:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25489 for ; Wed, 20 Feb 2002 08:43:27 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08303 for ; Wed, 20 Feb 2002 08:43:26 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dZpp-0000jm-00; Wed, 20 Feb 2002 08:43:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Haberman Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Configuring Routers References: <4.3.2.7.2.20020219171004.025b7538@mailhost.iprg.nokia.com> <4.3.2.7.2.20020220074024.025f8808@mailhost.iprg.nokia.com> <3C73CC09.D7063632@innovationslab.net> Message-Id: Date: Wed, 20 Feb 2002 08:43:13 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You answered all the questions in Bob's note except this one. > And it is the most important one. :) >>> To bring this back to the thread, do you think there is a need for a >>> protocol here or are the current solutions adequate? no. i answered it. essentially, it may be worthwhile, but under no circumstances should it be cute or complex. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 08:54:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGsfKL023980 for ; Wed, 20 Feb 2002 08:54:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KGsfM7023979 for ipng-dist; Wed, 20 Feb 2002 08:54:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGsbKL023972 for ; Wed, 20 Feb 2002 08:54:37 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08560 for ; Wed, 20 Feb 2002 08:54:39 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03670 for ; Wed, 20 Feb 2002 08:54:38 -0800 (PST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1KGsVo71003; Thu, 21 Feb 2002 01:54:31 +0900 (JST) Date: Thu, 21 Feb 2002 01:54:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of necessary changes for rfc2292bis In-Reply-To: <3C73C1AB.F09CB83E@zk3.dec.com> References: <3C73C1AB.F09CB83E@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 20 Feb 2002 10:32:59 -0500, >>>>> Vladislav Yasevich said: >> - 6.2: IPV6_PKTINFO should be forbidden for TCP > ... > I guess I missed the discussion above the above bullet. I > don't believe it should be explicitely forbidden. Specifying > the outgoing interface may be a useful feature. Oops, I oversimplified this item. It should have been: if the ipi6_addr member for IPV6_PKTINFO on a TCP socket is non the unspecified address, the call should fail. (FYI: the current text is: the ipi6_addr member should be ignored when the option is specified for a TCP socket) Thanks for the correction. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 09:23:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHNXKL024048 for ; Wed, 20 Feb 2002 09:23:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KHNWQc024047 for ipng-dist; Wed, 20 Feb 2002 09:23:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHNPKL024040 for ; Wed, 20 Feb 2002 09:23:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15023 for ; Wed, 20 Feb 2002 09:23:28 -0800 (PST) Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [210.163.32.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26949 for ; Wed, 20 Feb 2002 09:23:27 -0800 (PST) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id CAA09040; Thu, 21 Feb 2002 02:23:15 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id CAA00738; Thu, 21 Feb 2002 02:23:15 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id CAA00711; Thu, 21 Feb 2002 02:23:13 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id CAA28679; Thu, 21 Feb 2002 02:23:10 +0900 (JST) Message-ID: <032f01c1ba33$56843d50$e4ff240a@local> From: "Yamasaki Toshi" To: "NOISETTE Yoann FTRD/DMI/CAE" , Cc: , "Lilian Fernandes" References: <91A311FF6A85D3118DDF0060080C3D8202C95CEB@lat3721.rd.francetelecom.fr> Subject: Re: PPP and Global Addresses Date: Thu, 21 Feb 2002 01:51:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIME-Autoconverted: from 8bit to quoted-printable by ms1-gw.noc.ntt.com id CAA00738 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1KHNRKL024041 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ah, now I understand what you mean. Excuse my slow brain :-) In my scenario for Dial-up or DSL access services, some kind of L2 authentication, CHAP or 802.1x for example, runs before AutomaticPrefixDelegation, and the delegating router gets a prefix from Authentication server, Radius for example. ----- Original Message ----- From: "NOISETTE Yoann FTRD/DMI/CAE" To: "'Yamasaki Toshi'" ; "NOISETTE Yoann FTRD/DMI/CAE" ; "Lilian Fernandes" ; Cc: Sent: Friday, February 15, 2002 7:55 PM Subject: RE: PPP and Global Addresses The draft-haberman-ipngwg-auto-prefix-01.txt says : "4.4 Prefix Delegation After the request is verified to be acceptable, the Delegating Router allocates the requested prefix size from its pool of available addresses. The creation and management of that pool is beyond the scope of this document, but it can be supposed that minimalistically a Delegating Router will be statically configured with a fixed pool." What I meant is that the pool used by the Delegating router, in which it takes the prefix it delegates to Requesting routers, could be set using the DHCPv6 option for prefix delegation. Actually, only static (I understand "manual") configuration is considered. For instance, when a Delegating router is asked for a prefix, and can't answer because it doesn't have enough resources any more, it could then rely on the DHCPv6 option to get another pool... and then proceed to the required Prefix Delegation. Sorry this was not clear, hope it is now ;-) Yoann -----Message d'origine----- De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Envoyé : vendredi 15 février 2002 11:44 Ŕ : NOISETTE Yoann FTRD/DMI/CAE; Lilian Fernandes; ipng@sunroof.eng.sun.com Cc : shouchun@us.ibm.com Objet : Re: PPP and Global Addresses > "PD (Automatic Prefix Delegation)" doesn't specify any means to set the > prefix pool the routers rely on for delegation, apart from a manual setting. Could you kindly explain what you mean by this sentence in another way? I did't get the point... > The DHCPv6 option could be used in this aim, and would be therefore > complementary to PD... > Moreover PD also deals with routing protocol negocation, and does then more > than just prefix delegation... This point is interesting in so far as the > reachability of the subnet(s) corresponding to the delegated prefix must be > achieved in a way or another... I believe PD and DHCP are not competing, but can live together, like RA and DHCP can do so at a subnet. My understanding is that PD is "third-party-serverless autoconfig" or "third-party-server independent autoconfig" and DHCP is "third-party-server dependent", because PD is for routers which actually delegate and route the delegated prefix, and DHCP is not necessarily so. > > Yoann > > -----Message d'origine----- > De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] > Envoye : jeudi 14 fevrier 2002 04:52 > A : Lilian Fernandes; ipng@sunroof.eng.sun.com > Cc : shouchun@us.ibm.com > Objet : Re: PPP and Global Addresses > > > > "PD (Automatic Prefix Delegation)" is one of the choices. > > draft-haberman-ipngwg-auto-prefix-01.txt > http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-01. > txt > > To solve all the configuration issues with DHCPv6 might be another good > choice, but I guess PD be a minimum requirement for those who want an > automatic prefix delegation mechanism for (for example) IPv6 access > services, and DHCPv6 would be an option for those who want more. > > ---Toshi Yamasaki / NTT Communications > > > Hi, > > > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks > > about the negotiation of the Interface-Identifier and specifies the > > Interface-Identifier Configuration Option. In this case the upper 64 bits > > are just fe80:: > > > > It does not mention if there is any standard way to configure a > > global/site-local prefix on a point-to-point link i.e. are there > > configuration options to let one side tell the other about a global > > prefix? > > > > Or is it just left upto the users at both ends to decide on a prefix > > somehow and then configure it on each end? > > > > I'm sorry if there is an RFC about this that I missed... > > > > Thanks, > > Lilian > > > > _____________________________________________________________________ > > > > Lilian Fernandes > > AIX TCP/IP Development - IBM Austin > > Tel: 512-838-7966 Fax: 512-838-3509 > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 09:23:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHNFKL024038 for ; Wed, 20 Feb 2002 09:23:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KHNFbk024037 for ipng-dist; Wed, 20 Feb 2002 09:23:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHNBKL024030 for ; Wed, 20 Feb 2002 09:23:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14945 for ; Wed, 20 Feb 2002 09:23:14 -0800 (PST) Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [210.163.32.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13952 for ; Wed, 20 Feb 2002 10:23:13 -0700 (MST) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id CAA09022; Thu, 21 Feb 2002 02:23:11 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id CAA00666; Thu, 21 Feb 2002 02:23:10 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id CAA00660; Thu, 21 Feb 2002 02:23:09 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id CAA28676; Thu, 21 Feb 2002 02:23:08 +0900 (JST) Message-ID: <032e01c1ba33$5547ecc0$e4ff240a@local> From: "Yamasaki Toshi" To: "Francis Dupont" , References: <200202201056.g1KAuWg43606@givry.rennes.enst-bretagne.fr> Subject: Re: PPP and Global Addresses Date: Thu, 21 Feb 2002 01:29:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: the conclusion is we should specify/finish/implement/deploy router > mechanisms ASAP, at least before IPv6 dialups become common. I absolutely agree. My current conclusion among exsitsing choices is: - APD for a customer whose CPE is a L3 Router - RA(+RFC2462, 3041, etc.) for a customer whose CPE is a Multi-link Subnet Router - DHCPv6 for a customer who prefer more managed enviroment, that is, DHCP --- Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 10:23:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KINOKL024242 for ; Wed, 20 Feb 2002 10:23:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KINOR7024241 for ipng-dist; Wed, 20 Feb 2002 10:23:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KINKKL024234 for ; Wed, 20 Feb 2002 10:23:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03514 for ; Wed, 20 Feb 2002 10:23:21 -0800 (PST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09348 for ; Wed, 20 Feb 2002 11:23:21 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7A2B09E8; Wed, 20 Feb 2002 10:27:05 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DE2A5110E; Wed, 20 Feb 2002 10:23:19 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1KINIR13263; Wed, 20 Feb 2002 13:23:18 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id NAA0000078032; Wed, 20 Feb 2002 13:23:17 -0500 (EST) Message-ID: <3C73E995.7F80056E@compaq.com> Date: Wed, 20 Feb 2002 13:23:17 -0500 From: Vladislav Yasevich Reply-To: vlad@zk3.dec.com X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of necessary changes for rfc2292bis References: <3C73C1AB.F09CB83E@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Oops, I oversimplified this item. It should have been: > > if the ipi6_addr member for IPV6_PKTINFO on a TCP socket is non the > unspecified address, the call should fail. > OK. That works for me. Thanks -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich IPv6 Project Lead Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Tel: (603) 884-1079 Nashua, NH 03062 Fax: (435) 514-6884 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 12:17:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KKHbKL024796 for ; Wed, 20 Feb 2002 12:17:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KKHbQD024795 for ipng-dist; Wed, 20 Feb 2002 12:17:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KKHWKL024788 for ; Wed, 20 Feb 2002 12:17:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15975 for ; Wed, 20 Feb 2002 12:17:31 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA05853 for ; Wed, 20 Feb 2002 13:17:30 -0700 (MST) Received: (qmail 20674 invoked from network); 20 Feb 2002 20:17:28 -0000 Received: from pd950f395.dip.t-dialin.net (HELO ??) (217.80.243.149) by mail.bieringer.de with SMTP; 20 Feb 2002 20:17:28 -0000 Date: Wed, 20 Feb 2002 21:17:47 +0100 From: Peter Bieringer To: Robert Elz cc: Maillist IPng Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries Message-ID: <59140000.1014236267@localhost> In-Reply-To: <1899.1014197424@brandenburg.cs.mu.OZ.AU> References: <44900000.1014192970@localhost> <60380000.1014155043@localhost> <20020220000527.C9645@pianosa.catch22.org> <1899.1014197424@brandenburg.cs.mu.OZ.AU> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) X-Echelon: GRU NSA GCHQ CIA Pentagon nuclear war terror anthrax X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Wednesday, February 20, 2002 04:30:24 PM +0700 Robert Elz wrote: > Date: Wed, 20 Feb 2002 09:16:10 +0100 > From: Peter Bieringer > Message-ID: <44900000.1014192970@localhost> > > | BTW: looks like the same problem occurs in the forward chaining > using | A6. > but there isn't in A6 - the address part of an A6 is always the > least significant N (128 - prefix len field of A6 record) bits of > the address, and the least significant bit of that is always the > least significant possible bit of the value - so the alignment used > in the A6 record, and the natural alignment of the address are > always the same (ie: some bits may be cleared, or ignored, but > they're never shifted around). Right indeed, but which wins? Let's assume following Correct setup (example from BIND ARM): $ORIGIN example.com. host IN A6 64 0:0:0:0:42::1 company.example1.net. $ORIGIN example1.net. company IN A6 0 3ffe:8050:201:1860:: Resulting address 3ffe:8050:201:1860:42::1 Buggy setup: $ORIGIN example.com. host IN A6 64 0:0:0:0:42::1 company.example1.net. $ORIGIN example1.net. company IN A6 0 3ffe:8050:201:1860:8000:: Resulting address 3ffe:8050:201:1860:8042::1 ? or Resulting address 3ffe:8050:201:1860:0042::1 ? Which one is ok? Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:11:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLBhKL024925 for ; Wed, 20 Feb 2002 13:11:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLBhTQ024924 for ipng-dist; Wed, 20 Feb 2002 13:11:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLBdKL024917 for ; Wed, 20 Feb 2002 13:11:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21717 for ; Wed, 20 Feb 2002 13:11:42 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22578 for ; Wed, 20 Feb 2002 14:11:41 -0700 (MST) Received: from kenawang ([192.168.1.47]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA19132 for ; Wed, 20 Feb 2002 13:11:25 -0800 (PST) Message-Id: <4.2.2.20020220160608.01fd3620@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 20 Feb 2002 16:09:51 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Last Call for draft-ietf-ipv6-3gpp-recommend-00.txt? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, The 3GPP design team believes that draft-ietf-ipv6-3gpp-recommend-00.txt is ready for last call as an Informational RFC. This draft has undergone a couple of rounds of WG review, and the 3GPP is already acting on its contents. Bob and Steve, if there are no objections from the WG, would please move to last call for this draft? Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:14:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLEmKL024945 for ; Wed, 20 Feb 2002 13:14:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLEmxk024944 for ipng-dist; Wed, 20 Feb 2002 13:14:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLEkKL024937 for ; Wed, 20 Feb 2002 13:14:46 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KLEHuX000575 for ; Wed, 20 Feb 2002 13:14:17 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KLEHoG000574 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 13:14:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0R7Fh012443 for ; Tue, 12 Feb 2002 16:27:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14672 for ; Tue, 12 Feb 2002 16:27:11 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23411 for ; Tue, 12 Feb 2002 16:27:10 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA16395; Tue, 12 Feb 2002 19:27:06 -0500 (EST) Date: Tue, 12 Feb 2002 19:27:06 -0500 (EST) From: Dan Lanciani Message-Id: <200202130027.TAA16395@ss10.danlan.com> To: ddl@ss10.danlan.com, ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py" wrote: |> Dan Lanciani wrote: |> An obvious reason would be that the one who wishes to subnet |> the /64 is not the same one who should have used a /48, with |> the former one having little control over the latter one. | |A dial-up connection gets a /48..... It's not clear how you can make (let alone enforce) that generalization. Consider multiple dial-up connections to a system whose connection to its upstream provider is itself a dial-up connection. Your definition is self-contradictory in such a case. You can't hand out multiple /48s if all you have is one. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:15:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLFGKL024955 for ; Wed, 20 Feb 2002 13:15:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLFGPm024954 for ipng-dist; Wed, 20 Feb 2002 13:15:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLFFKL024947 for ; Wed, 20 Feb 2002 13:15:15 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KLEjuX000583 for ; Wed, 20 Feb 2002 13:14:45 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KLEjYW000582 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 13:14:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D95kFh013331 for ; Wed, 13 Feb 2002 01:05:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22388 for ; Wed, 13 Feb 2002 01:05:48 -0800 (PST) Received: from dakiya.controlnet.co.in (dakiya.controlnet.co.in.116.54.202.IN-ADDR.ARPA [202.54.116.69] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21598 for ; Wed, 13 Feb 2002 02:05:47 -0700 (MST) Received: from digambar ([192.168.4.1]) by dakiya.controlnet.co.in (Netscape Messaging Server 4.15) with ESMTP id GRGSB800.J0B for ; Wed, 13 Feb 2002 14:43:56 +0530 Message-ID: <008c01c1b46e$0de10ee0$9c01a8c0@digambar> From: "Digambar Rasal" To: Subject: Ipv6 Arp Date: Wed, 13 Feb 2002 14:38:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01C1B49C.27760B70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C1B49C.27760B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have presently a system in which we are using IPv4 and now we are = implementating IPv6 . But the problem i have come across is how we are = going to change the ARP process. I mean can we use ARP with new 16 byte = ipaddresses or we have to use some other process for address resolution? Regards Digambar ------=_NextPart_000_0089_01C1B49C.27760B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
We have presently a system in which we = are using=20 IPv4 and now  we are implementating IPv6 . But the problem i = have come=20 across is how we are going to change the ARP process. I mean can we use = ARP with=20 new 16 byte ipaddresses or we have to use some other process for address = resolution?
 
Regards
Digambar
 
------=_NextPart_000_0089_01C1B49C.27760B70-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:17:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLHLKL024984 for ; Wed, 20 Feb 2002 13:17:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLHLqw024983 for ipng-dist; Wed, 20 Feb 2002 13:17:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLHJKL024976 for ; Wed, 20 Feb 2002 13:17:19 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KLGouX000607 for ; Wed, 20 Feb 2002 13:16:50 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KLGout000606 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 13:16:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F99DKL006807 for ; Fri, 15 Feb 2002 01:09:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12317 for ; Fri, 15 Feb 2002 01:09:14 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA00910 for ; Fri, 15 Feb 2002 02:09:12 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4WZ016>; Fri, 15 Feb 2002 10:08:34 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201E3D524@lat3721.rd.francetelecom.fr> From: BINET David FTRD/DMI/CAE To: "'Ole Troan'" , Francis Dupont Cc: Lilian Fernandes , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 10:08:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cf280e3d-209a-11d6-ac1f-00508b692753" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-cf280e3d-209a-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B600.54477930" ------_=_NextPart_001_01C1B600.54477930 Content-Type: text/plain I did not attend the IPng meeting in May 2001 in Redmond and in the minutes I do not see the reasons why DHCPv6 protocol is not appropriate for router prefix delegation. For several contexts, I think that we need some protocols or some extensions to make the prefix router delegation possible, and as it has been proposed by Ole, the new DHCP options can fit the needs. So, what are the reasons why DHCPv6 is not appropriate for such use ? Thanks David Binet -----Message d'origine----- De : Ole Troan [mailto:ot@cisco.com] Envoye : jeudi 14 fevrier 2002 20:34 A : Francis Dupont Cc : Lilian Fernandes; ipng@sunroof.eng.sun.com; shouchun@us.ibm.com Objet : Re: PPP and Global Addresses > In your previous mail you wrote: > > > http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt > > (search for Dialup Architecture, note this is my last attempt to find > > an usefulness to DHCPv6 :-). > > we're just about to suggest a couple of new DHCPv6 options for this > purpose. > > => you may but don't forget the vote was 0 (zero) in favour of DHCPv6 > and at least Steve Deering is publicly strongly opposed to use DHCPv6 > for router configuration. I'll let Steve speak for himself. it turns out that router to router prefix delegation has a number of conceptual similarities with statefull address assignment. instead of making a new protocol evolve into DHCP under a different name, I suggest we reconsider the use of DHCP. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1B600.54477930 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

I did not attend the IPng meeting in May 2001 in = Redmond and in the minutes I do not see the reasons why DHCPv6 protocol = is not appropriate for router prefix delegation.

For several contexts, I think that we need some = protocols or some extensions to make the prefix router delegation = possible, and as it has been proposed by Ole, the new DHCP options can = fit the needs.

So, what are the reasons why DHCPv6 is not = appropriate for such use ?

Thanks
David Binet 

-----Message d'origine-----
De : Ole Troan [mailto:ot@cisco.com]
Envoye : jeudi 14 fevrier 2002 20:34
A : Francis Dupont
Cc : Lilian Fernandes; ipng@sunroof.eng.sun.com; = shouchun@us.ibm.com
Objet : Re: PPP and Global Addresses


>  In your previous mail you wrote:
>
>    > http://playground.sun.com/pub/ipng/html/minutes/ipng-m= eeting-may2001.txt
>    > (search for Dialup = Architecture, note this is my last attempt to find
>    > an usefulness to DHCPv6 = :-).
>   
>    we're just about to suggest a = couple of new DHCPv6 options for this
>    purpose.
>   
> =3D> you may but don't forget the vote was 0 = (zero) in favour of DHCPv6
> and at least Steve Deering is publicly strongly = opposed to use DHCPv6
> for router configuration.

I'll let Steve speak for himself.

it turns out that router to router prefix delegation = has a number of
conceptual similarities with statefull address = assignment. instead of
making a new protocol evolve into DHCP under a = different name, I
suggest we reconsider the use of DHCP.

/ot
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1B600.54477930-- ------=_NextPartTM-000-cf280e3d-209a-11d6-ac1f-00508b692753-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:17:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLHrKL024994 for ; Wed, 20 Feb 2002 13:17:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLHr6c024993 for ipng-dist; Wed, 20 Feb 2002 13:17:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLHiKL024986 for ; Wed, 20 Feb 2002 13:17:45 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KLHBuX000615 for ; Wed, 20 Feb 2002 13:17:11 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KLHBvp000614 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 13:17:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FA48KL006934 for ; Fri, 15 Feb 2002 02:04:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17958 for ; Fri, 15 Feb 2002 02:04:11 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA16130 for ; Fri, 15 Feb 2002 02:04:06 -0800 (PST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4W5AHL>; Fri, 15 Feb 2002 11:03:31 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95CE6@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Yamasaki Toshi'" , Lilian Fernandes , ipng@sunroof.eng.sun.com Cc: shouchun@us.ibm.com Subject: RE: PPP and Global Addresses Date: Fri, 15 Feb 2002 11:03:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cf280fe4-209a-11d6-ac1f-00508b692753" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-cf280fe4-209a-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B608.0015B220" ------_=_NextPart_001_01C1B608.0015B220 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable "PD (Automatic Prefix Delegation)" doesn't specify any means to set the prefix pool the routers rely on for delegation, apart from a manual = setting. The DHCPv6 option could be used in this aim, and would be therefore complementary to PD... Moreover PD also deals with routing protocol negocation, and does then = more than just prefix delegation... This point is interesting in so far as = the reachability of the subnet(s) corresponding to the delegated prefix = must be achieved in a way or another... Yoann -----Message d'origine----- De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Envoy=E9 : jeudi 14 f=E9vrier 2002 04:52 =C0 : Lilian Fernandes; ipng@sunroof.eng.sun.com Cc : shouchun@us.ibm.com Objet : Re: PPP and Global Addresses "PD (Automatic Prefix Delegation)" is one of the choices. draft-haberman-ipngwg-auto-prefix-01.txt http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix= -01. txt To solve all the configuration issues with DHCPv6 might be another good choice, but I guess PD be a minimum requirement for those who want an automatic prefix delegation mechanism for (for example) IPv6 access services, and DHCPv6 would be an option for those who want more. ---Toshi Yamasaki / NTT Communications > Hi, > > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC = talks > about the negotiation of the Interface-Identifier and specifies the > Interface-Identifier Configuration Option. In this case the upper 64 = bits > are just fe80:: > > It does not mention if there is any standard way to configure a > global/site-local prefix on a point-to-point link i.e. are there > configuration options to let one side tell the other about a global > prefix? > > Or is it just left upto the users at both ends to decide on a prefix > somehow and then configure it on each end? > > I'm sorry if there is an RFC about this that I missed... > > Thanks, > Lilian > > _____________________________________________________________________ > > Lilian Fernandes > AIX TCP/IP Development - IBM Austin > Tel: 512-838-7966 Fax: 512-838-3509 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1B608.0015B220 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

"PD (Automatic Prefix Delegation)" doesn't = specify any means to set the prefix pool the routers rely on for = delegation, apart from a manual setting.

The DHCPv6 option could be used in this aim, and = would be therefore complementary to PD...
Moreover PD also deals with routing protocol = negocation, and does then more than just prefix delegation... This = point is interesting in so far as the reachability of the subnet(s) = corresponding to the delegated prefix must be achieved in a way or = another...

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com]=
Envoy=E9 : jeudi 14 f=E9vrier 2002 04:52
=C0 : Lilian Fernandes; = ipng@sunroof.eng.sun.com
Cc : shouchun@us.ibm.com
Objet : Re: PPP and Global Addresses


"PD (Automatic Prefix Delegation)" is one = of the choices.

draft-haberman-ipngwg-auto-prefix-01.txt
http://search.ietf.org/internet-drafts/draft-haberman-= ipngwg-auto-prefix-01.
txt

To solve all the configuration issues with DHCPv6 = might be another good
choice, but I guess PD be a minimum requirement for = those who want an
automatic prefix delegation mechanism for (for = example) IPv6 access
services,  and DHCPv6 would be an option for = those who want more.

---Toshi Yamasaki / NTT Communications

> Hi,
>
> I have a question about RFC2472 - "IP = Version 6 over PPP". The RFC talks
> about the negotiation of the = Interface-Identifier and specifies the
> Interface-Identifier Configuration Option. In = this case the upper 64 bits
> are just fe80::
>
> It does not mention if there is any standard = way to configure a
> global/site-local prefix on a point-to-point = link i.e. are there
> configuration options to let one side tell the = other about a global
> prefix?
>
> Or is it just left upto the users at both ends = to decide on a prefix
> somehow and then configure it on each = end?
>
> I'm sorry if there is an RFC about this that I = missed...
>
> Thanks,
> Lilian
>
> = _____________________________________________________________________
>
> Lilian Fernandes
> AIX TCP/IP Development - IBM Austin
> Tel: 512-838-7966 Fax: 512-838-3509
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>
>

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1B608.0015B220-- ------=_NextPartTM-000-cf280fe4-209a-11d6-ac1f-00508b692753-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:18:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLIsKL025028 for ; Wed, 20 Feb 2002 13:18:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLIrCu025027 for ipng-dist; Wed, 20 Feb 2002 13:18:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLIpKL025017 for ; Wed, 20 Feb 2002 13:18:51 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KLIMuX000623 for ; Wed, 20 Feb 2002 13:18:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KLIMMm000622 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 13:18:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KIe2KL024357 for ; Wed, 20 Feb 2002 10:40:02 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07077 for ; Wed, 20 Feb 2002 10:40:04 -0800 (PST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29707 for ; Wed, 20 Feb 2002 10:40:03 -0800 (PST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id KAA19515 for ; Wed, 20 Feb 2002 10:40:01 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 20 Feb 2002 18:40:01 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id KAA07966 for ; Wed, 20 Feb 2002 10:39:29 -0800 (PST) Received: from hrnmail.eng.ascend.com (hrnmail.eng.ascend.com [135.114.245.5]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id KAA14165 for ; Wed, 20 Feb 2002 10:39:28 -0800 (PST) Received: from R505JL (hrnmail [135.114.245.5]) by hrnmail.eng.ascend.com (8.10.2/8.10.2) with ESMTP id g1KI6BF15136 for ; Wed, 20 Feb 2002 13:06:11 -0500 (EST) From: "Dave Saunders" To: Subject: Proxy ARP Under IPv6 Date: Wed, 20 Feb 2002 13:06:06 -0500 Message-ID: <010301c1ba39$45765650$720fb5d8@R505JL> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01C1BA0F.5CA04E50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0104_01C1BA0F.5CA04E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the equivalent solution to Proxy ARP under IPv6? I am working on a system that needs to have a single interface collect packets that are not necessarily destined for it. Thanks, Dave ------=_NextPart_000_0104_01C1BA0F.5CA04E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the equivalent solution to Proxy ARP under = IPv6? I am working on a system that needs to have a single interface collect = packets that are not necessarily destined for it.

 

Thanks,

Dave

 

------=_NextPart_000_0104_01C1BA0F.5CA04E50-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:21:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLL6KL025111 for ; Wed, 20 Feb 2002 13:21:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLL4cm025100 for ipng-dist; Wed, 20 Feb 2002 13:21:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLKvKL025086 for ; Wed, 20 Feb 2002 13:20:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06493 for ; Wed, 20 Feb 2002 13:20:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15745 for ; Wed, 20 Feb 2002 14:20:55 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1KLKof28891; Wed, 20 Feb 2002 23:20:50 +0200 Date: Wed, 20 Feb 2002 23:20:49 +0200 (EET) From: Pekka Savola To: Digambar Rasal cc: ipng@sunroof.eng.sun.com Subject: Re: Ipv6 Arp In-Reply-To: <008c01c1b46e$0de10ee0$9c01a8c0@digambar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 13 Feb 2002, Digambar Rasal wrote: > We have presently a system in which we are using IPv4 and now we are > implementating IPv6 . But the problem i have come across is how we are > going to change the ARP process. I mean can we use ARP with new 16 byte > ipaddresses or we have to use some other process for address resolution? The core features of ARP are integrated in ICMPv6 protocol. See RFC 2461. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:24:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLO5KL025324 for ; Wed, 20 Feb 2002 13:24:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLO5bv025323 for ipng-dist; Wed, 20 Feb 2002 13:24:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLO2KL025316 for ; Wed, 20 Feb 2002 13:24:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25371 for ; Wed, 20 Feb 2002 13:24:05 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09288 for ; Wed, 20 Feb 2002 13:24:05 -0800 (PST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA42170; Wed, 20 Feb 2002 15:33:12 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA28584; Wed, 20 Feb 2002 15:24:00 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g1KLNx229342; Wed, 20 Feb 2002 15:23:59 -0600 Date: Wed, 20 Feb 2002 15:23:58 -0600 (CST) From: Lilian Fernandes To: Digambar Rasal cc: Subject: Re: Ipv6 Arp In-Reply-To: <008c01c1b46e$0de10ee0$9c01a8c0@digambar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPV6 defines the Neighbor Discovery process to do this. See RFC2461. Lilian On Wed, 13 Feb 2002, Digambar Rasal wrote: > Hi, > > We have presently a system in which we are using IPv4 and now we are implementating IPv6 . But the problem i have come across is how we are going to change the ARP process. I mean can we use ARP with new 16 byte ipaddresses or we have to use some other process for address resolution? > > Regards > Digambar > > _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:25:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLPDKL025356 for ; Wed, 20 Feb 2002 13:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLPD1I025355 for ipng-dist; Wed, 20 Feb 2002 13:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLP6KL025348 for ; Wed, 20 Feb 2002 13:25:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25627 for ; Wed, 20 Feb 2002 13:25:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17913 for ; Wed, 20 Feb 2002 14:24:46 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1KLObZ28920; Wed, 20 Feb 2002 23:24:37 +0200 Date: Wed, 20 Feb 2002 23:24:37 +0200 (EET) From: Pekka Savola To: NOISETTE Yoann FTRD/DMI/CAE cc: "'Yamasaki Toshi'" , Lilian Fernandes , , Subject: RE: PPP and Global Addresses In-Reply-To: <91A311FF6A85D3118DDF0060080C3D8202C95CE6@lat3721.rd.francetelecom.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Feb 2002, NOISETTE Yoann FTRD/DMI/CAE wrote: > "PD (Automatic Prefix Delegation)" doesn't specify any means to set the > prefix pool the routers rely on for delegation, apart from a manual setting. > The DHCPv6 option could be used in this aim, and would be therefore > complementary to PD... That can also be seen as a feature. I certainly do. (Note that e.g. with proposed address allocation proposals, you're supposed to document the use of /48's in the registries.. how do you do that with a prefix pool?). > The DHCPv6 option could be used in this aim, and would be therefore > complementary to PD... Moreover PD also deals with routing protocol > negocation, and does then more than just prefix delegation... This point > is interesting in so far as the reachability of the subnet(s) > corresponding to the delegated prefix must be achieved in a way or > another... IMO, protocol negotiation seems to be almost always extra cruft. I don't see it used at all where APD applies the best. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:25:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLPqKL025386 for ; Wed, 20 Feb 2002 13:25:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLPqNQ025385 for ipng-dist; Wed, 20 Feb 2002 13:25:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLPmKL025378 for ; Wed, 20 Feb 2002 13:25:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08678 for ; Wed, 20 Feb 2002 13:25:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18440 for ; Wed, 20 Feb 2002 14:25:49 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1KLPj828945; Wed, 20 Feb 2002 23:25:45 +0200 Date: Wed, 20 Feb 2002 23:25:45 +0200 (EET) From: Pekka Savola To: Dave Saunders cc: ipng@sunroof.eng.sun.com Subject: Re: Proxy ARP Under IPv6 In-Reply-To: <010301c1ba39$45765650$720fb5d8@R505JL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Feb 2002, Dave Saunders wrote: > What is the equivalent solution to Proxy ARP under IPv6? I am working on > a system that needs to have a single interface collect packets that are > not necessarily destined for it. Proxy Neighbour Advertisements, see RFC2461 7.2.8 etc. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 13:35:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLZGKL025617 for ; Wed, 20 Feb 2002 13:35:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KLZGfQ025616 for ipng-dist; Wed, 20 Feb 2002 13:35:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KLZCKL025609 for ; Wed, 20 Feb 2002 13:35:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12030 for ; Wed, 20 Feb 2002 13:35:16 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23415 for ; Wed, 20 Feb 2002 14:35:15 -0700 (MST) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KEJ2RDKAZ48Y8VF3@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 21 Feb 2002 08:34:47 +1100 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id E91E720002; Wed, 20 Feb 2002 21:34:46 +0000 (/etc/localtime) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 727B220002; Thu, 21 Feb 2002 08:34:46 +1100 (EST) Date: Thu, 21 Feb 2002 08:33:56 +1100 From: Greg Daley Subject: Re: Proxy ARP Under IPv6 To: Dave Saunders Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3C741644.B08B2CA5@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <010301c1ba39$45765650$720fb5d8@R505JL> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, Neighbour Discovery is used for this Please read RFC2461 for details. Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 15:34:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KNY7KL025948 for ; Wed, 20 Feb 2002 15:34:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KNY6qs025947 for ipng-dist; Wed, 20 Feb 2002 15:34:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KNY3KL025940 for ; Wed, 20 Feb 2002 15:34:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27022 for ; Wed, 20 Feb 2002 15:34:06 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04150 for ; Wed, 20 Feb 2002 15:34:03 -0800 (PST) Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g1KNYI118527; Thu, 21 Feb 2002 10:34:20 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200202202334.g1KNYI118527@drugs.dv.isc.org> To: Peter Bieringer Cc: Robert Elz , Maillist IPng From: Mark.Andrews@isc.org Subject: Re: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries In-reply-to: Your message of "Wed, 20 Feb 2002 21:17:47 BST." <59140000.1014236267@localhost> Date: Thu, 21 Feb 2002 10:34:18 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > --On Wednesday, February 20, 2002 04:30:24 PM +0700 Robert Elz > wrote: > > > Date: Wed, 20 Feb 2002 09:16:10 +0100 > > From: Peter Bieringer > > Message-ID: <44900000.1014192970@localhost> > > > > | BTW: looks like the same problem occurs in the forward chaining > > using | A6. > > > > but there isn't in A6 - the address part of an A6 is always the > > least significant N (128 - prefix len field of A6 record) bits of > > the address, and the least significant bit of that is always the > > least significant possible bit of the value - so the alignment used > > in the A6 record, and the natural alignment of the address are > > always the same (ie: some bits may be cleared, or ignored, but > > they're never shifted around). > > Right indeed, but which wins? > > > Let's assume following > > Correct setup (example from BIND ARM): > > $ORIGIN example.com. > host IN A6 64 0:0:0:0:42::1 company.example1.net. > > $ORIGIN example1.net. > company IN A6 0 3ffe:8050:201:1860:: > > Resulting address 3ffe:8050:201:1860:42::1 > > > Buggy setup: > > $ORIGIN example.com. > host IN A6 64 0:0:0:0:42::1 company.example1.net. > > $ORIGIN example1.net. > company IN A6 0 3ffe:8050:201:1860:8000:: > > > Resulting address 3ffe:8050:201:1860:8042::1 ? > or > Resulting address 3ffe:8050:201:1860:0042::1 ? > > Which one is ok? 3ffe:8050:201:1860:0042::1 > > Peter > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 15:56:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KNu3KL026020 for ; Wed, 20 Feb 2002 15:56:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KNu3KG026019 for ipng-dist; Wed, 20 Feb 2002 15:56:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KNu2KL026012 for ; Wed, 20 Feb 2002 15:56:02 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1KNtWuX002944 for ; Wed, 20 Feb 2002 15:55:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1KNtWPP002943 for ipng@sunroof.eng.sun.com; Wed, 20 Feb 2002 15:55:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KNfxKL025985 for ; Wed, 20 Feb 2002 15:41:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00356 for ; Wed, 20 Feb 2002 15:42:01 -0800 (PST) Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00483 for ; Wed, 20 Feb 2002 15:42:01 -0800 (PST) Received: from tukia (203-79-84-109.adsl.paradise.net.nz [203.79.84.109]) by deborah.paradise.net.nz (Postfix) with SMTP id D774AD2128; Thu, 21 Feb 2002 12:41:59 +1300 (NZDT) Message-ID: <005d01c1ba68$2b360450$4e07a8c0@tukia> From: "Sean Lin" To: "Robert Elz" Cc: References: <3C6CF67F.30.4C1A3CAD@localhost> <1830.1013750875@brandenburg.cs.mu.OZ.AU> Subject: Re: PPP and VLAN link-local addresses Date: Thu, 21 Feb 2002 12:41:50 +1300 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.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > | I was wondering if this has been mentioned before. > > It has been discussed before. It is a truly wonderful idea... > > If it could be done, there'd be no adverse effects, the problem > is how the extra identifier gets distributed to the nodes. Your > average system has no idea what its vlan-id might happen to be (not > that there's any reason to restrict the usage that way). it doesn't matter i reckon. I mean from the other nodes point of view it's just another link-local address ( well, as long as when it determines what the address type is, it matches for fe80::/10 and not fe80::/64 > > It cannot use the net to discover the id, as at the stage it is > configuring its link local address, it has no way to use the net. > > The earlier suggestion kept the 0's in the format on the wire, and > just used the id for local internal identification (within the node). > That means that each node cinvent its own numbers, they don't need to > be consistent with those chosen by anyone else. But having the > address the node uses different from the one passed to other nodes > complicates any protocol that actually uses the value of the address > (the node has to know to use the address with the ID in it for addressing, > but the address with 0's replacing the ID for all other purposes, which is > messy). > > In any case, this suggestion went nowhere. as long as the node continues to use,e.g. fe80::1:2c0:dfff:fe07:6d62 for the specified interface i don't see why this would be a problem to other nodes. Only when implementations start matching to the /64 boundary instead of the /10 boundary this may be a problem. using the format fe80:::, would allow a single link-local addresses to be shared among various interfaces on the node and will also enable the node to determine which interface a destination link-local address is going out of. Also, why not fe80::: instead of address%? Then you wouldn't have problems described in draft-ietf-ipngwg-scoping-arch-03.txt for URLs but then again it would be difficult to say fe80:eth0:: or fe80:vlan0:: unless you can map eth0 and vlan0 or vlan1 to a standardised numerical index or value. Regards, Sean -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 20 19:57:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1L3v1KL026492 for ; Wed, 20 Feb 2002 19:57:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1L3v06I026491 for ipng-dist; Wed, 20 Feb 2002 19:57:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1L3uvKL026484 for ; Wed, 20 Feb 2002 19:56:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15422 for ; Wed, 20 Feb 2002 19:57:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27208 for ; Wed, 20 Feb 2002 20:56:56 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1L3xVk01778; Thu, 21 Feb 2002 10:59:32 +0700 (ICT) From: Robert Elz To: "Sean Lin" cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and VLAN link-local addresses In-Reply-To: <005d01c1ba68$2b360450$4e07a8c0@tukia> References: <005d01c1ba68$2b360450$4e07a8c0@tukia> <3C6CF67F.30.4C1A3CAD@localhost> <1830.1013750875@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Feb 2002 10:59:31 +0700 Message-ID: <1776.1014263971@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 21 Feb 2002 12:41:50 +1300 From: "Sean Lin" Message-ID: <005d01c1ba68$2b360450$4e07a8c0@tukia> I don't think there is a lot of point having this discussion again, so this will be my last message about it, but ... | I mean from the other nodes point of view it's | just another link-local address ( well, as long as | when it determines what the address type is, it matches for fe80::/10 and | not fe80::/64 But that, and ... | using the format fe80:::, would allow a single link-local | addresses | to be shared among various interfaces on the node and will also enable the | node to determine | which interface a destination link-local address is going out of. that are incompatible. Either the specifies the interface (and thus is a part of the prefix, not the per link identifier), or it does not, you can't really have it both ways. You also need to consider what happens when the address reaches another node, consider A which has 5 interfaces (1, 2, 3, 4, 5 are the id's we'll assign to those), and B which also has 5 interfaces (and big surprise, since it comes from the same vendor, it also calls them 1 2 3 4 5). Then know that the link from interface 2 on A connects to interface 4 on B. Now A sends a packet from its LL addr fe80::2:wwww:xxxx:yyyy:zzzz B gets that packet and wants to reply to that address, the '2' in there was A's interface number, means nothing to B at all (certainly sending out interface 2 won't work). It is possible to make all of this work (B would see the packet arrived on the interface it calls 4, and rewrite the address to fe80::4:wwww:xxxx:yyyy:zzzz but now the nodes need to be aware that the part of the address is volatile. The other approach, and the one that was actually suggested when this was proposed, is for A to actually put fe80::wwww:xxxx:yyyy:zzzz in the packets it sends. This allows B to just use current methods if it prefers, and means that everyone can predict what the address on the wire will be, which simplifies (a little) the protocol implications. That is, the id in the LL address would be used only in the API, not on the wire. | Also, why | not fe80::: | instead of address%? Then you wouldn't have problems described in | draft-ietf-ipngwg-scoping-arch-03.txt for URLs Yes, that was the attraction of this approach, it would simplify the user interface (and API)_, at the expense of complicating the protocols. I suspect that the decision is mostly based upon the observation that the human interface to link local addresses is very rarely ever used, most applications will be told to use other addresses, most of the time. Only net manager type people are likely to manually ever use LL addresses (especially when there is more than one active link to cause confusion). And most of the API details can be buried inside library routines, so applications mostly don't have to care wither way. On the other hand, all protocols have to deal with the possibility that they might be told to use LL addresses, and so everything is going to have to deal with the implications of that if the addressses suddenly started to contain volatile components (something different on the wire, or at the remote node, from what the application sees). In any case, you can rest assured that this was all considered in the past (5-6 years ago now I think) - it isn't just something that no-one considered. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 00:40:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1L8ePKL026697 for ; Thu, 21 Feb 2002 00:40:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1L8eOsv026696 for ipng-dist; Thu, 21 Feb 2002 00:40:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1L8eJKL026689 for ; Thu, 21 Feb 2002 00:40:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16952 for ; Thu, 21 Feb 2002 00:40:19 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17583 for ; Thu, 21 Feb 2002 00:40:18 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:bc64:975a:9aa7:395f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1L8e3o76858; Thu, 21 Feb 2002 17:40:03 +0900 (JST) Date: Thu, 21 Feb 2002 17:39:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: Query regarding loopback interface In-Reply-To: References: <20020212061255.27232.qmail@mailweb15.rediffmail.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 14 Feb 2002 07:47:11 -0800, >>>>> Steve Deering said: > The loopback link does not require a link-local address. If you have > virtual links that can have more than one node attached (e.g., some > people refer to an IP tunnel as a virtual link), those links will > need link-local addresses for the (virtually) attached nodes. This is quite reasonable, but seems to contradict a requirement in the address architecture draft: All interfaces are required to have at least one link-local unicast address (see section 2.8 for additional required addresses). (draft-ietf-ipngwg-addr-arch-v3-07.txt, Section 2.1) We may have to clarify this point before the draft is in an RFC status. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 07:26:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFQ7KL027417 for ; Thu, 21 Feb 2002 07:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LFQ6Cf027416 for ipng-dist; Thu, 21 Feb 2002 07:26:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFQ3KL027409 for ; Thu, 21 Feb 2002 07:26:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07591 for ; Thu, 21 Feb 2002 07:26:05 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06666 for ; Thu, 21 Feb 2002 08:26:04 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 21 Feb 2002 21:12:12 +0530 Received: from chakraa (chakraa.future.futsoft.com [10.4.7.5]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g1LFPAM05355 for ; Thu, 21 Feb 2002 20:55:10 +0530 Reply-To: From: "chakri" To: Subject: Setting Traffic Class using setsockopt Date: Thu, 21 Feb 2002 20:47:52 +0530 Message-Id: <002101c1baea$eefc24a0$0507040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to set traffic class field using IPv6 sockets. When I use a struct sockaddr_in6 (with SOCK_DGRAM or SOCK_STREAM) I can't set the fields (there are always in 0, i check it with ethereal). I tried using IPV6_FLOWINFO_SEND, but connect () errs " invalid argument" Any pointers? -Chakri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 07:45:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFjiKL027472 for ; Thu, 21 Feb 2002 07:45:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LFjiEN027471 for ipng-dist; Thu, 21 Feb 2002 07:45:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFjfKL027464 for ; Thu, 21 Feb 2002 07:45:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19868 for ; Thu, 21 Feb 2002 07:45:42 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16548 for ; Thu, 21 Feb 2002 08:45:40 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id CC8AE4314C for ; Thu, 21 Feb 2002 16:45:36 +0100 (CET) Received: from lmserv2.lab.it.uc3m.es (lmserv2.lab.it.uc3m.es [163.117.144.152]) by smtp01.uc3m.es (Postfix) with ESMTP id 8A4A499E03 for ; Thu, 21 Feb 2002 16:45:35 +0100 (CET) Received: from it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by lmserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id QAA21257 for ; Thu, 21 Feb 2002 16:45:35 +0100 Message-ID: <3C75161F.81C23C95@it.uc3m.es> Date: Thu, 21 Feb 2002 16:45:35 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "(Lista) ipng@sunroof.eng.sun.com" Subject: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello: I have a question related to IPv6 configuration over a LANE interface. Maybe someone here could help me :-) I have the following configuration on a CISCO router with IOS version 12.2(T): %%% BEGIN OF CONFIGURATION %%% [snip] ! interface ATM0/1/0 ip address no ip mroute-cache no atm ilmi-keepalive pvc 0/5 qsaal ! pvc ILMI 0/16 ilmi ilmi manage ! pvc 0/40 protocol ip broadcast ! ! interface ATM0/1/0.1 point-to-point description red TEST troncal ip address pvc TEST 0/100 protocol ip vbr-nrt 2000 2000 64000 encapsulation aal5snap ! ! interface ATM0/1/0.2 multipoint description LANE - Red TEST local ip address ipv6 enable ipv6 address ::/64 eui-64 ipv6 mtu 4470 lane server-atm-address 47.000580FFE1000000F21A866B.0020481A866B.42 lane client ethernet [snip] ! %%%% END OF CONFIGURATION %%%%% My question is: IPv4 works fine through LANE, but IPv6 don't. Its necessary to do something else ?? (I know very little about ATM and/or LANE protocols :-)) Thank you very much. ***** JFRH ***** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 08:06:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LG6SKL027721 for ; Thu, 21 Feb 2002 08:06:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LG6RIv027720 for ipng-dist; Thu, 21 Feb 2002 08:06:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LG6OKL027710 for ; Thu, 21 Feb 2002 08:06:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15613 for ; Thu, 21 Feb 2002 08:06:26 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05550 for ; Thu, 21 Feb 2002 09:06:25 -0700 (MST) Subject: RE: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Feb 2002 08:06:21 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DECB@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) Thread-Index: AcG672uABdEUBdyERlWBKJ6i07WUNwAAJTnw From: "Michel Py" To: "Juan Francisco Rodriguez Hervella" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1LG6OKL027711 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juan, I doubt this config would work. Lane is bridging a lan over the ATM cloud. There are several issues with IPv6 bridging and Cisco: 1. AFAIK, it is not implemented in 12.2(T) (neither BVI or RBE) 2. Cisco will not implement IPv6 for BVI interfaces. 3. I do not know if Cisco will support LANE for IPv6. In any case, you need to try RBE (see http://www.cisco.com/warp/public/794/routed_bridged_encap.html), and add the "atm route-bridged ip" command to ATM0/1/0.2, but this is not likely to work with 12.2(T). Michel -----Original Message----- From: Juan Francisco Rodriguez Hervella [mailto:jrh@it.uc3m.es] Sent: Thursday, February 21, 2002 7:46 AM To: (Lista) ipng@sunroof.eng.sun.com Subject: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) Hello: I have a question related to IPv6 configuration over a LANE interface. Maybe someone here could help me :-) I have the following configuration on a CISCO router with IOS version 12.2(T): %%% BEGIN OF CONFIGURATION %%% [snip] ! interface ATM0/1/0 ip address no ip mroute-cache no atm ilmi-keepalive pvc 0/5 qsaal ! pvc ILMI 0/16 ilmi ilmi manage ! pvc 0/40 protocol ip broadcast ! ! interface ATM0/1/0.1 point-to-point description red TEST troncal ip address pvc TEST 0/100 protocol ip vbr-nrt 2000 2000 64000 encapsulation aal5snap ! ! interface ATM0/1/0.2 multipoint description LANE - Red TEST local ip address ipv6 enable ipv6 address ::/64 eui-64 ipv6 mtu 4470 lane server-atm-address 47.000580FFE1000000F21A866B.0020481A866B.42 lane client ethernet [snip] ! %%%% END OF CONFIGURATION %%%%% My question is: IPv4 works fine through LANE, but IPv6 don't. Its necessary to do something else ?? (I know very little about ATM and/or LANE protocols :-)) Thank you very much. ***** JFRH ***** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 08:26:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGQ5KL027782 for ; Thu, 21 Feb 2002 08:26:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LGQ5s3027781 for ipng-dist; Thu, 21 Feb 2002 08:26:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGQ2KL027774 for ; Thu, 21 Feb 2002 08:26:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19568 for ; Thu, 21 Feb 2002 08:26:04 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08243 for ; Thu, 21 Feb 2002 09:26:03 -0700 (MST) Subject: RE: I-D ACTION:draft-savola-ipv6-127-prefixlen-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2002 08:25:58 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C370@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savola-ipv6-127-prefixlen-01.txt Thread-Index: AcG65f5NgESItdaTTUqG6D+OsBU/zAADmxDw From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1LGQ2KL027775 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looks good to me. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, February 21, 2002 4:01 AM Subject: I-D ACTION:draft-savola-ipv6-127-prefixlen-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Note about the Use of IPv6 /127 Prefix Length Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-01.txt Pages : 4 Date : 20-Feb-02 In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-01.t xt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-ipv6-127-prefixlen-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-ipv6-127-prefixlen-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 08:31:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGVTKL027808 for ; Thu, 21 Feb 2002 08:31:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LGVTlE027807 for ipng-dist; Thu, 21 Feb 2002 08:31:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGVPKL027800 for ; Thu, 21 Feb 2002 08:31:26 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20192 for ; Thu, 21 Feb 2002 08:31:28 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27939 for ; Thu, 21 Feb 2002 08:31:27 -0800 (PST) Received: from TWARWICK-W2K1.cisco.com (lon-sto4-lan-vlan133-dhcp17.cisco.com [144.254.108.84]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA21737; Thu, 21 Feb 2002 16:31:20 GMT Message-Id: <4.3.2.7.2.20020221162457.048f95b0@mrwint.cisco.com> X-Sender: twarwick@mrwint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 16:29:08 +0000 To: Juan Francisco Rodriguez Hervella From: Trevor Warwick Subject: Re: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) Cc: "(Lista) ipng@sunroof.eng.sun.com" In-Reply-To: <3C75161F.81C23C95@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please direct any questions about IPv6 in released Cisco IOS images to the TAC, or email ipv6-support@cisco.com if you are using an EFT image. Thanks, Trevor Warwick At 21/02/2002, Juan Francisco Rodriguez Hervella wrote: >Hello: > >I have a question related to IPv6 configuration over a LANE interface. >Maybe >someone here could help me :-) >I have the following configuration on a CISCO router with IOS version >12.2(T): > >%%% BEGIN OF CONFIGURATION %%% >[snip] >! >interface ATM0/1/0 > ip address > no ip mroute-cache > no atm ilmi-keepalive > pvc 0/5 qsaal > ! > pvc ILMI 0/16 ilmi > ilmi manage > ! > pvc 0/40 > protocol ip broadcast >! >! >interface ATM0/1/0.1 point-to-point > description red TEST troncal > ip address > pvc TEST 0/100 > protocol ip > vbr-nrt 2000 2000 64000 > encapsulation aal5snap >! >! >interface ATM0/1/0.2 multipoint > description LANE - Red TEST local > ip address > ipv6 enable > ipv6 address ::/64 eui-64 > ipv6 mtu 4470 > lane server-atm-address 47.000580FFE1000000F21A866B.0020481A866B.42 > lane client ethernet >[snip] >! >%%%% END OF CONFIGURATION %%%%% > >My question is: > >IPv4 works fine through LANE, but IPv6 don't. >Its necessary to do something else ?? >(I know very little about ATM and/or LANE protocols :-)) > >Thank you very much. > >***** >JFRH >***** > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 08:34:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGYtKL027833 for ; Thu, 21 Feb 2002 08:34:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LGYtBV027832 for ipng-dist; Thu, 21 Feb 2002 08:34:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LGYqKL027825 for ; Thu, 21 Feb 2002 08:34:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20861 for ; Thu, 21 Feb 2002 08:34:54 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00118 for ; Thu, 21 Feb 2002 08:34:53 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA21910; Thu, 21 Feb 2002 16:34:50 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Juan Francisco Rodriguez Hervella Cc: "(Lista) ipng@sunroof.eng.sun.com" Subject: Re: IPv6 over LANE pseudo-interface doesn't work, suggestions are very wellcome :-) References: <3C75161F.81C23C95@it.uc3m.es> From: Ole Troan Date: Thu, 21 Feb 2002 16:34:50 +0000 In-Reply-To: <3C75161F.81C23C95@it.uc3m.es> (Juan Francisco Rodriguez Hervella's message of "Thu, 21 Feb 2002 16:45:35 +0100") Message-ID: <7t5pu2yn68l.fsf@mrwint.cisco.com> Lines: 75 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juan, the IPng list is not the right place for vendor specific support questions. please contact your cisco support representative, or a public mailing list specific to cisco products, or read the documentation, or if you are running IPv6 IOS EFT software contact ipv6-support@cisco.com, or best of all do not use LANE. just to comment on Mr Py's reply; LANE is supported in 12.2T, and does not have anything to do with bridging or RBE. /ot > I have a question related to IPv6 configuration over a LANE interface. > Maybe > someone here could help me :-) > I have the following configuration on a CISCO router with IOS version > 12.2(T): > > %%% BEGIN OF CONFIGURATION %%% > [snip] > ! > interface ATM0/1/0 > ip address > no ip mroute-cache > no atm ilmi-keepalive > pvc 0/5 qsaal > ! > pvc ILMI 0/16 ilmi > ilmi manage > ! > pvc 0/40 > protocol ip broadcast > ! > ! > interface ATM0/1/0.1 point-to-point > description red TEST troncal > ip address > pvc TEST 0/100 > protocol ip > vbr-nrt 2000 2000 64000 > encapsulation aal5snap > ! > ! > interface ATM0/1/0.2 multipoint > description LANE - Red TEST local > ip address > ipv6 enable > ipv6 address ::/64 eui-64 > ipv6 mtu 4470 > lane server-atm-address 47.000580FFE1000000F21A866B.0020481A866B.42 > lane client ethernet > [snip] > ! > %%%% END OF CONFIGURATION %%%%% > > My question is: > > IPv4 works fine through LANE, but IPv6 don't. > Its necessary to do something else ?? > (I know very little about ATM and/or LANE protocols :-)) > > Thank you very much. > > ***** > JFRH > ***** > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 21 12:09:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LK9nKL028334 for ; Thu, 21 Feb 2002 12:09:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LK9nvR028333 for ipng-dist; Thu, 21 Feb 2002 12:09:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LK9kKL028326 for ; Thu, 21 Feb 2002 12:09:46 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19804 for ; Thu, 21 Feb 2002 12:09:48 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18163 for ; Thu, 21 Feb 2002 12:09:48 -0800 (PST) Subject: RE: IPv6 over LANE pseudo-interface doesn't work, suggestions arevery wellcome :-) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2002 12:09:45 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DECF@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 over LANE pseudo-interface doesn't work, suggestions arevery wellcome :-) Thread-Index: AcG69lL29vproGIkRJixG3sfS+Qf4wAHL7SQ From: "Michel Py" To: "Ole Troan" , "Juan Francisco Rodriguez Hervella" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1LK9kKL028327 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ole Troan wrote: > or best of all do not use LANE. Not using a router will also solve the problem. > LANE is supported in 12.2T, and does not have > anything to do with bridging LANE is the ATM community's answer to the VLAN and its purpose is, indeed, to use an ATM link as a trunk to bridge subnets across the ATM cloud. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 22 07:48:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MFmUKL000274 for ; Fri, 22 Feb 2002 07:48:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MFmUCn000273 for ipng-dist; Fri, 22 Feb 2002 07:48:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MFmQKL000263 for ; Fri, 22 Feb 2002 07:48:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11654 for ; Fri, 22 Feb 2002 07:48:28 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13989 for ; Fri, 22 Feb 2002 08:48:27 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:b58f:942d:88f8:e401]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MFmIo88173; Sat, 23 Feb 2002 00:48:18 +0900 (JST) Date: Sat, 23 Feb 2002 00:48:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Cc: Subject: Re: Setting Traffic Class using setsockopt In-Reply-To: <002101c1baea$eefc24a0$0507040a@future.futsoft.com> References: <002101c1baea$eefc24a0$0507040a@future.futsoft.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 21 Feb 2002 20:47:52 +0530, >>>>> "chakri" said: > I am trying to set traffic class field using IPv6 sockets. > When I use a struct sockaddr_in6 (with SOCK_DGRAM or SOCK_STREAM) I can't > set the fields (there are always in 0, i check it with ethereal). See Section 6.5 of draft-ietf-ipngwg-rfc2292bis-05.txt. (note, however, that this option is quite new and few OSes support this.) > I tried using IPV6_FLOWINFO_SEND, but connect () errs " invalid argument" > Any pointers? I've never heard IPV6_FLOWINFO_SEND. This is at least a non-standard option that you should not depend on. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 23 03:03:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1NB3pKL001784 for ; Sat, 23 Feb 2002 03:03:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1NB3pY8001783 for ipng-dist; Sat, 23 Feb 2002 03:03:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1NB3mKL001776 for ; Sat, 23 Feb 2002 03:03:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04631 for ; Sat, 23 Feb 2002 03:03:48 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09969 for ; Sat, 23 Feb 2002 04:03:47 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1NB3eB22813; Sat, 23 Feb 2002 13:03:41 +0200 Date: Sat, 23 Feb 2002 13:03:40 +0200 (EET) From: Pekka Savola To: lutchann@litech.org cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-lutchann-ipv6-delegate-option-00.txt In-Reply-To: <200202211200.HAA13803@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Feb 2002 Internet-Drafts@ietf.org wrote: > > > Title : IPv6 Router Advertisement Prefix Delegation Option > Author(s) : N. Lutchansky > Filename : draft-lutchann-ipv6-delegate-option-00.txt > Pages : > Date : 20-Feb-02 > > This document defines the Prefix Delegation (PD) option used to > delegate IPv6 address space to simple IPv6 sites. The PD option, > which lists the global prefixes that a site may use to number its > network, is attached to IPv6 Neighbor Discovery Router Advertisement > messages that are sent across a point-to-point link from a provider's > router to a site's border router. This document defines the > mechanism by which a site router processes the PD option and > configures each of its attached links allowing hosts within the site > to obtain global addresses using address autoconfiguration. A few comments. 2. Terminology ==> is necessary to define basic stuff like 'node' and router here. A reference to RFC2460 or whatever should be sufficient? 3.3. Site router operation Upon receiving a Router Solicitation message containing a Prefix Delegation option, the router MUST process the message as described in [DISCOVERY] and [ADDRCONF] before processing the PD option. ==> Router Advertisement, not Solication? PD should only be used in RA. 4. Prefix Delegation option format Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 64. ==> The format supports anything from 0 to 128, when though some of those make no sense. 5. Security considerations Security issues regarding the Neighbor Discovery protocol are discussed in [DISCOVERY]. ==> doesn't PD bring up any new issues? Bring more weight to existing ones? I bet it does :-). For example, if the point-to-point link is an IPv6/IPv4 tunnel, it might be possible to inject RA packets with bogus PD options.. General comments: this would affect how routers (that is, CPE) work wrt. NDISC: basically the point-to-point link towards the ISP would have to operate in "host" mode so it could sent RS's and be able to receive RA's. I think changes to the current specification need to spelled out in a separate chapter. One might also consider whether CPE should immediately send out RA's with a new prefix (and advertise the old one with lifetime of zero or whatever) when the prefix delegated from upstream changes. I'd move acknowledgements from introduction to a separate chapter, as is usual. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 03:22:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PBMfKL004254 for ; Mon, 25 Feb 2002 03:22:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PBMfoL004253 for ipng-dist; Mon, 25 Feb 2002 03:22:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PBMbKL004246 for ; Mon, 25 Feb 2002 03:22:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24295 for ; Mon, 25 Feb 2002 03:22:38 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25299 for ; Mon, 25 Feb 2002 03:22:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04779; Mon, 25 Feb 2002 06:22:34 -0500 (EST) Message-Id: <200202251122.GAA04779@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-park-host-based-mcast-01.txt Date: Mon, 25 Feb 2002 06:22:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host-based IPv6 Multicast Addresses Allocation Author(s) : J. Park et al. Filename : draft-park-host-based-mcast-01.txt Pages : 5 Date : 22-Feb-02 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for sing interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without needing to run an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-host-based-mcast-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-park-host-based-mcast-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-park-host-based-mcast-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020222110511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-host-based-mcast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-host-based-mcast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222110511.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 14:39:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMdpKL005474 for ; Mon, 25 Feb 2002 14:39:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMdpeb005473 for ipng-dist; Mon, 25 Feb 2002 14:39:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMdnKL005466 for ; Mon, 25 Feb 2002 14:39:49 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1PMdEuX004707 for ; Mon, 25 Feb 2002 14:39:14 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1PMdDV2004706 for ipng@sunroof.eng.sun.com; Mon, 25 Feb 2002 14:39:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MBWuKL029964 for ; Fri, 22 Feb 2002 03:32:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19138 for ; Fri, 22 Feb 2002 03:32:57 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11222 for ; Fri, 22 Feb 2002 04:32:56 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MBXQi25598 for ; Fri, 22 Feb 2002 13:33:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Feb 2002 13:32:55 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Feb 2002 13:32:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Minimum IPv6 Functionality for a Cellular Host -00 IPv6 wg document Date: Fri, 22 Feb 2002 13:32:55 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F919DD1@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some editorial comments Thread-Index: AcG7FtURGyS2caPjSsGna8h87nNPdgAYASnQAAFrddAAAToVoAABeDTQAAAWg5AAAH/g4AAAb1oAAAA55qAAAX3DgAAAGqMQ To: X-OriginalArrivalTime: 22 Feb 2002 11:32:55.0227 (UTC) FILETIME=[ABA3B0B0:01C1BB94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1MBWuKL029965 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! I'm happy to announce a new version of our draft "Minimum IPv6 Functionality for a Cellular Host". This draft will become a -00 wg document for IPv6 wg. Before our draft is publicly announced, it is available here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-cellular-host-00.txt Please read the draft remembering that Your comments are appreciated a lot! All questions considering our draft can be sent to the authors and the IPv6 wg mailing list. Best Regards, Juha Wiljakka - - - Minimum IPv6 Functionality for a Cellular Host Abstract As an increasing number of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, UMTS, and CDMA2000 terminals. Standardization organizations are also making IPv6 mandatory in their newest specifications, such as the IP multimedia terminals specified for UMTS. However, the concept of IPv6 covers many aspects, numerous RFCs, a number of different situations, and is also partly still evolving. A rapid adoption of IPv6 is desired for cellular hosts. Yet these terminals vary greatly in terms of their processing capabilities and task orientation. Cellular host software often cannot be upgraded and must still meet tough demands for interoperability with other hosts, the cellular network, and the Internet. For these reasons it is necessary to understand how the IPv6 deployment starts and which parts of IPv6 are necessary under which situations. This document suggests basic IPv6 functionality for cellular hosts, and discusses when parts of the functionality is needed, and under which conditions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 14:41:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMfEKL005491 for ; Mon, 25 Feb 2002 14:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMfEB7005490 for ipng-dist; Mon, 25 Feb 2002 14:41:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMfDKL005483 for ; Mon, 25 Feb 2002 14:41:13 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1PMebuX004715 for ; Mon, 25 Feb 2002 14:40:37 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1PMebEi004714 for ipng@sunroof.eng.sun.com; Mon, 25 Feb 2002 14:40:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PD3FKL004368 for ; Mon, 25 Feb 2002 05:03:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22192 for ; Mon, 25 Feb 2002 05:03:16 -0800 (PST) Received: from ns.fmmo.ca (237-65-250.tr.cgocable.ca [205.237.65.250]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29992 for ; Mon, 25 Feb 2002 06:03:16 -0700 (MST) Received: from ap340.fmmo.ca ([192.168.1.152] helo=NYQUIST.fmmo.ca) by ns.fmmo.ca with esmtp (Exim 3.34 #1 (Debian)) id 16fKnY-00081T-00 for ; Mon, 25 Feb 2002 08:04:08 -0500 Date: Mon, 25 Feb 2002 08:03:13 -0500 (Eastern Standard Time) From: Francois Menard To: ipng@sunroof.eng.sun.com Subject: IPv6 and BGP peering In-Reply-To: Message-ID: X-X-Sender: fm-listproc@ns.fmmo.ca MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there a document which describes in details IPv6 multi-homing (in the context of public NAPs). Does one ISP need to get a /35 at a minimum in order to be globally routable on the public IPv6 Internet? f. -- Francois D. Menard fmenard@fmmo.ca -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 14:55:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMtCKL005640 for ; Mon, 25 Feb 2002 14:55:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMtCsW005639 for ipng-dist; Mon, 25 Feb 2002 14:55:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMt9KL005632 for ; Mon, 25 Feb 2002 14:55:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26777 for ; Mon, 25 Feb 2002 14:55:10 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14827 for ; Mon, 25 Feb 2002 15:55:09 -0700 (MST) Subject: RE: IPv6 and BGP peering MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Feb 2002 14:55:05 -0800 content-class: urn:content-classes:message Message-ID: <2B81403386729140A3A899A8B39B046405DEE1@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 and BGP peering Thread-Index: AcG+TfiL3EMUz8KYRyejGPxE0osYfgAAIeUQ From: "Michel Py" To: "Francois Menard" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1PMt9KL005633 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Francois D. Menard wrote: > Does one ISP need to get a /35 at a minimum in order to be > globally routable on the public IPv6 Internet? As of today, yes. Needs to become a subTLA. See: http://www.arin.net/regserv/ipv6/ipv6guidelines.html Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 14:56:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMuVKL005677 for ; Mon, 25 Feb 2002 14:56:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMuVI3005676 for ipng-dist; Mon, 25 Feb 2002 14:56:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMuPKL005669 for ; Mon, 25 Feb 2002 14:56:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14602 for ; Mon, 25 Feb 2002 14:56:26 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16689 for ; Mon, 25 Feb 2002 15:56:25 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1PMu6t22228; Tue, 26 Feb 2002 00:56:07 +0200 Date: Tue, 26 Feb 2002 00:56:06 +0200 (EET) From: Pekka Savola To: Francois Menard cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 and BGP peering In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Feb 2002, Francois Menard wrote: > Is there a document which describes in details IPv6 multi-homing (in the > context of public NAPs). > > Does one ISP need to get a /35 at a minimum in order to be globally > routable on the public IPv6 Internet? This is a routing policy issue, not a subject for ipng I think. 6bone@isi.edu would be one list, multi6 another. There is a '6bone routing guidelines' RFC. (currently about /35 is required.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 15:03:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PN3TKL005777 for ; Mon, 25 Feb 2002 15:03:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PN3SAA005776 for ipng-dist; Mon, 25 Feb 2002 15:03:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PN3PKL005769 for ; Mon, 25 Feb 2002 15:03:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16383 for ; Mon, 25 Feb 2002 15:03:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20051 for ; Mon, 25 Feb 2002 16:03:26 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA16501; Mon, 25 Feb 2002 15:03:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1PN3IK21691; Mon, 25 Feb 2002 15:03:18 -0800 X-mProtect:  Mon, 25 Feb 2002 15:03:18 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSUCgvd; Mon, 25 Feb 2002 15:03:15 PST Message-Id: <4.3.2.7.2.20020225145816.0272ad60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Feb 2002 15:02:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Request for Agenda Items for IETF 53 IPv6 Sessions Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group has been scheduled for two sessions at the Minneapolis IETF. They are: MONDAY, March 18, 2002, 1930-2200 THURSDAY, March 21, 2002, 0900-1130 Note that these date and times are subject to change by the IETF secretariat. Please send us requests for agenda items. When we put together the agenda we plan to give priority to current working group activities and documents, new individual submissions, and last to status reports. Thanks, Bob Hinden / Steve Deering IPv6 Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 25 15:28:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PNS0KL005853 for ; Mon, 25 Feb 2002 15:28:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PNS0Js005852 for ipng-dist; Mon, 25 Feb 2002 15:28:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PNRvKL005845 for ; Mon, 25 Feb 2002 15:27:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08371 for ; Mon, 25 Feb 2002 15:27:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25656 for ; Mon, 25 Feb 2002 16:27:53 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18428; Mon, 25 Feb 2002 15:27:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1PNRoP27608; Mon, 25 Feb 2002 15:27:50 -0800 X-mProtect:  Mon, 25 Feb 2002 15:27:50 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk66S1d; Mon, 25 Feb 2002 15:27:23 PST Message-Id: <4.3.2.7.2.20020225152334.02797ed0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Feb 2002 15:26:05 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Recommendations for IPv6 in 3GPP Standards" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-00.txt Pages : 22 Date : 22-Jan-02 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on March 11, 2002. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 26 01:09:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q99gKL006500 for ; Tue, 26 Feb 2002 01:09:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1Q99fTb006499 for ipng-dist; Tue, 26 Feb 2002 01:09:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q99YKL006492 for ; Tue, 26 Feb 2002 01:09:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21536 for ; Tue, 26 Feb 2002 01:09:35 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26613 for ; Tue, 26 Feb 2002 02:09:34 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:f8ad:ffb5:f9be:fffd]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1Q99Wo12767 for ; Tue, 26 Feb 2002 18:09:32 +0900 (JST) Date: Tue, 26 Feb 2002 18:09:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: summary of necessary changes for rfc2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 21 Feb 2002 00:08:33 +0900, >>>>> JINMEI Tatuya said: > I'll soon make the changes above and submit the 06 revision of the > draft. If I miss something, please point it out. I submitted the 06 revision yesterday, but it will be available a bit later because this is a busy season. For the moment, a local copy of the draft is available at http://www.kame.net/~jinmei/draft-ietf-ipngwg-rfc2292bis-06.txt When it is officially out, I'll ask the chairs for the second last call. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 04:22:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCMoKL008777 for ; Wed, 27 Feb 2002 04:22:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RCMoUv008776 for ipng-dist; Wed, 27 Feb 2002 04:22:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCMkKL008769 for ; Wed, 27 Feb 2002 04:22:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11074 for ; Wed, 27 Feb 2002 04:22:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24722 for ; Wed, 27 Feb 2002 05:22:47 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17676; Wed, 27 Feb 2002 07:22:43 -0500 (EST) Message-Id: <200202271222.HAA17676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-flow-label-00.txt Date: Wed, 27 Feb 2002 07:22:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme et al. Filename : draft-ietf-ipv6-flow-label-00.txt Pages : 8 Date : 26-Feb-02 This document specifies the usage of the IPv6 flow label field, the requirements for hosts labeling flows, and the requirements for flow state establishment methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-flow-label-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-flow-label-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130241.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 09:07:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RH7qKL009370 for ; Wed, 27 Feb 2002 09:07:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RH7qZp009369 for ipng-dist; Wed, 27 Feb 2002 09:07:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RH7nKL009362 for ; Wed, 27 Feb 2002 09:07:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05247 for ; Wed, 27 Feb 2002 09:07:52 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27417 for ; Wed, 27 Feb 2002 10:07:51 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1RH7mk11263 for ; Wed, 27 Feb 2002 18:07:49 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA11474 for ; Wed, 27 Feb 2002 18:07:49 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1RH7ng78991 for ; Wed, 27 Feb 2002 18:07:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202271707.g1RH7ng78991@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: draft-dupont-ipv6-payload-01.txt Date: Wed, 27 Feb 2002 18:07:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need someone to help me for the second version (as explained in proceedings of last IETF meeting): >Strong consensus to not continue this work. Dupont will write draft >that discusses pros and cons and show why this should not be done. Any volunteer? Deadline is this Friday! Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 11:10:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJABKL010036 for ; Wed, 27 Feb 2002 11:10:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJAARi010035 for ipng-dist; Wed, 27 Feb 2002 11:10:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJA6KL010022 for ; Wed, 27 Feb 2002 11:10:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10325 for ; Wed, 27 Feb 2002 11:10:08 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01919 for ; Wed, 27 Feb 2002 11:10:00 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 13BC143137 for ; Wed, 27 Feb 2002 20:09:59 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id D743199E06 for ; Wed, 27 Feb 2002 20:09:58 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id UAA12843 for ; Wed, 27 Feb 2002 20:09:58 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id UAA12450 for ; Wed, 27 Feb 2002 20:09:58 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: Subject: About RFC 1887 Date: Wed, 27 Feb 2002 20:11:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 1887 states: "4.3.2 Indirect Providers (Backbones) There does not at present appear to be a strong case for direct providers to take their address spaces from the the IPv6 space of an indirect provider (e.g., backbone). The benefit in routing data abstraction is relatively small. The number of direct providers today is in the tens and an order of magnitude increase would not cause an undue burden on the backbones. Also, it may be expected that as time goes by there will be increased direct interconnection of the direct providers, leaf routing domains directly attached to the backbones, and international links directly attached to the providers. Under these circumstances, the distinction between direct and indirect providers may become blurred. An additional factor that discourages allocation of IPv6 addresses from a backbone prefix is that the backbones and their attached providers are perceived as being independent. Providers may take their long-haul service from one or more backbones, or may switch backbones should a more cost-effective service be provided elsewhere. Having IPv6 addresses derived from a backbone is inconsistent with the nature of the relationship." Is this coherent with TLA and NLA asignment rules presented in RFC 2450 and with RFC 2374? Also, RFC 1887 proposes a multi-homing solution (solution 1) based on " One possible solution is for each multi-homed organization to obtain its IPv6 address space independently of the providers to which it is attached" Is this solution compatible with RFC 2450 and RFC 2374? Regards, marcelo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 18:14:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S2EnKL011862 for ; Wed, 27 Feb 2002 18:14:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S2EntM011861 for ipng-dist; Wed, 27 Feb 2002 18:14:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S2EkKL011854 for ; Wed, 27 Feb 2002 18:14:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27045 for ; Wed, 27 Feb 2002 18:14:47 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13772 for ; Wed, 27 Feb 2002 19:14:47 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 27 Feb 2002 18:14:45 -0800 From: "Tony Hain" To: "marcelo bagnulo" , Subject: RE: About RFC 1887 Date: Wed, 27 Feb 2002 18:14:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marcelo, The TLA/NLA rules are obsolete, as the RIRs are managing the space without the TLA/NLA designations. See draft-ietf-ipngwg-addr-arch-v3-07.txt as a replacement for RFC 2374. The multi-6 working group is tasked with addressing appropriate multi-homing mechanisms. While the requirements are still being worked out, I have 2 drafts that discuss a possible approach and the policy issues involved. See draft-hain-ipv6-pi-addr-01.txt & draft-hain-ipv6-pi-addr-use-01.txt. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of marcelo bagnulo > Sent: Wednesday, February 27, 2002 11:11 AM > To: ipng@sunroof.eng.sun.com > Subject: About RFC 1887 > > > RFC 1887 states: > "4.3.2 Indirect Providers (Backbones) > > > There does not at present appear to be a strong case for direct > providers to take their address spaces from the the IPv6 > space of an > indirect provider (e.g., backbone). The benefit in routing data > abstraction is relatively small. The number of direct > providers today > is in the tens and an order of magnitude increase would > not cause an > undue burden on the backbones. Also, it may be expected > that as time > goes by there will be increased direct interconnection of > the direct > providers, leaf routing domains directly attached to the backbones, > and international links directly attached to the providers. Under > these circumstances, the distinction between direct and indirect > providers may become blurred. > > An additional factor that discourages allocation of IPv6 addresses > from a backbone prefix is that the backbones and their attached > providers are perceived as being independent. Providers may take > their long-haul service from one or more backbones, or may switch > backbones should a more cost-effective service be provided > elsewhere. > Having IPv6 addresses derived from a backbone is inconsistent with > the nature of the relationship." > > Is this coherent with TLA and NLA asignment rules presented > in RFC 2450 and > with RFC 2374? > > Also, RFC 1887 proposes a multi-homing solution (solution 1) based on > > " One possible solution is for each multi-homed organization > to obtain > its IPv6 address space independently of the providers to > which it is > attached" > > Is this solution compatible with RFC 2450 and RFC 2374? > > Regards, marcelo > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 21:58:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S5wfKL012294 for ; Wed, 27 Feb 2002 21:58:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S5wfpM012293 for ipng-dist; Wed, 27 Feb 2002 21:58:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S5wbKL012286 for ; Wed, 27 Feb 2002 21:58:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28320 for ; Wed, 27 Feb 2002 21:58:40 -0800 (PST) Received: from mailweb21.rediffmail.com ([203.199.83.145]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA13092 for ; Wed, 27 Feb 2002 22:58:38 -0700 (MST) Received: (qmail 19463 invoked by uid 510); 28 Feb 2002 05:57:12 -0000 Date: 28 Feb 2002 05:57:12 -0000 Message-ID: <20020228055712.19462.qmail@mailweb21.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 28 Feb 2002 05:57:12 -0000 MIME-Version: 1.0 From: "IPSix Developer" Reply-To: "IPSix Developer" To: ipng@sunroof.eng.sun.com Subject: ping6 with IPSEC policy Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1) In our FreeBSD machines, kernel is compiled with IPSEC options (IPSEC, IPSEC_ESP, IPSEC_DEBUG) . While trying ping6 using the configured policy (using: ping6 -P ), the message "unable to set IPSEC policy" is coming. Any soulution for this? 2) consider the following setup (All are FreeBSD machines): H1----R1-----R2-----R3------H2 Policies (AH, Tunnelmode, hmac-md)are configured successfully in R1 and R3. When Ping6 is initiated from H1 to H2, packets coming from R1 do not contain AH header. But there is a reply from H2 without AH header. How to make R1 to send IP packets with Security headers. thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 23:55:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7tVKL012599 for ; Wed, 27 Feb 2002 23:55:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7tVqq012598 for ipng-dist; Wed, 27 Feb 2002 23:55:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7tSKL012591 for ; Wed, 27 Feb 2002 23:55:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19228 for ; Wed, 27 Feb 2002 23:55:29 -0800 (PST) Received: from mail0.epfl.ch (mail0.epfl.ch [128.178.50.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA04970 for ; Thu, 28 Feb 2002 00:55:24 -0700 (MST) Received: (qmail 7502 invoked from network); 28 Feb 2002 07:55:22 -0000 Received: from littmp3.epfl.ch (HELO ganymede) (128.178.151.5) by mail0.epfl.ch with SMTP; 28 Feb 2002 07:55:22 -0000 From: Laurent Toutain To: ipng@sunroof.eng.sun.com Cc: richier@imag.fr, Octavio Medina , Francis Dupont Date: Thu, 28 Feb 2002 08:51:22 +0100 X-Priority: 3 (Normal) Reply-To: Laurent.Toutain@enst-bretagne.fr Organization: ENST Bretagne Departement RSM In-Reply-To: <20020228055712.19462.qmail@mailweb21.rediffmail.com> Message-Id: <2WLFRL73CAKEYX7592Z7554LI4ZJD9.3c7de17a@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Opera 6.0 build 1010 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have issued a draft http://search.ietf.org/internet-drafts/draft-richier-dstm-vpn-00.txt This draft documents a way to use current specification of DSTM, to access to a IPv4 network from a remote IPv6 network. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 27 23:56:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7uhKL012616 for ; Wed, 27 Feb 2002 23:56:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7uhWq012615 for ipng-dist; Wed, 27 Feb 2002 23:56:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7ueKL012608 for ; Wed, 27 Feb 2002 23:56:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28716 for ; Wed, 27 Feb 2002 23:56:40 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16924 for ; Thu, 28 Feb 2002 00:56:39 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g1S7uU118047 for ; Thu, 28 Feb 2002 08:56:30 +0100 (MET) To: ipng@sunroof.eng.sun.com Subject: RFC 3056 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 28 Feb 2002 08:56:28 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/28/2002 08:56:30, Serialize complete at 02/28/2002 08:56:30 Content-Type: multipart/alternative; boundary="=_alternative 002B9F20C1256B6E_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 002B9F20C1256B6E_= Content-Type: text/plain; charset="us-ascii" Hi, I have a question on the relay router in the 6to4 transition model of RFC 3056: R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 (relay router) Note: R1 is a pure 6to4 router; R2 and R3 are part of the IPv4 cloud; R5 is a relay router. In the 6to4 model R1 and R4 need to have a 6to4 address. From RFC 3056 I understand that these 6to4 addresses have to be configured on the interface between R1 and R2 (R4 and R3) respectively. I am now puzzled between the following 2 observations: 1) I would also expect to have an IPv6 address configured on R2's end of the R1-R2 interface. After all, only configuring an IPv6 address on 1 of the routers connected to an interface would be a bit strange? A similar remark holds for R3 on the R4-R3 interface. 2) However, no IPv6 address should be assigned to R2 (R3) since R2 (R3) is only IPv4 capable? Can somebody clarify the apparent contradiction between both statements? Thanks. Francis. --=_alternative 002B9F20C1256B6E_= Content-Type: text/html; charset="us-ascii"
Hi,

I have a question on the relay router in the 6to4 transition model of RFC 3056:

        R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 (relay router)


Note: R1 is a pure 6to4 router; R2 and R3 are part of the IPv4 cloud; R5 is a relay router.


In the 6to4 model R1 and R4 need to have a 6to4 address. From RFC 3056 I understand that these 6to4 addresses have to be configured on the interface between R1 and R2 (R4 and R3) respectively. I am now puzzled between the following 2 observations:
1) I would also expect to have an IPv6 address configured on R2's end of the R1-R2 interface. After all, only configuring an IPv6 address on 1 of the routers connected to an interface would be a bit strange? A similar remark holds for R3 on the R4-R3 interface.
2) However, no IPv6 address should be assigned to R2 (R3) since R2 (R3) is only IPv4 capable?



Can somebody clarify the apparent contradiction between both statements? Thanks.

        Francis. --=_alternative 002B9F20C1256B6E_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 02:22:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SAMAKL012967 for ; Thu, 28 Feb 2002 02:22:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SAM9sp012966 for ipng-dist; Thu, 28 Feb 2002 02:22:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SAM6KL012959 for ; Thu, 28 Feb 2002 02:22:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22098 for ; Thu, 28 Feb 2002 02:22:08 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27560 for ; Thu, 28 Feb 2002 03:22:07 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1SALtN24967; Thu, 28 Feb 2002 12:21:56 +0200 Date: Thu, 28 Feb 2002 12:21:55 +0200 (EET) From: Pekka Savola To: francis.arts@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote: > R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 (relay router) > > Note: R1 is a pure 6to4 router; R2 and R3 are part of the IPv4 cloud; R5 > is a relay router. > > In the 6to4 model R1 and R4 need to have a 6to4 address. From RFC 3056 I > understand that these 6to4 addresses have to be configured on the > interface between R1 and R2 (R4 and R3) respectively. I am now puzzled > between the following 2 observations: > 1) I would also expect to have an IPv6 address configured on R2's end of > the R1-R2 interface. After all, only configuring an IPv6 address on 1 of > the routers connected to an interface would be a bit strange? A similar > remark holds for R3 on the R4-R3 interface. > 2) However, no IPv6 address should be assigned to R2 (R3) since R2 (R3) is > only IPv4 capable? It's 6to4 _pseudo_ - interface :-). It's not assigned (normally) on any physical link. The only address you need between R1-R2 and R3-R4 are IPv4 addresses (from which, a 6to4 address may be derived from). HTH, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 04:00:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SC0hKL013092 for ; Thu, 28 Feb 2002 04:00:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SC0gUX013091 for ipng-dist; Thu, 28 Feb 2002 04:00:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SC0dKL013084 for ; Thu, 28 Feb 2002 04:00:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00982 for ; Thu, 28 Feb 2002 04:00:40 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09440 for ; Thu, 28 Feb 2002 04:00:38 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DE21443147; Thu, 28 Feb 2002 13:00:36 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id 3A25C99E03; Thu, 28 Feb 2002 13:00:36 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id NAA04392; Thu, 28 Feb 2002 13:00:34 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id NAA24362; Thu, 28 Feb 2002 13:00:28 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: "Tony Hain" , Subject: RE: About RFC 1887 Date: Thu, 28 Feb 2002 13:01:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > De: Tony Hain [mailto:alh-ietf@tndh.net] > > The TLA/NLA rules are obsolete, as the RIRs are managing the space > without the TLA/NLA designations. See > draft-ietf-ipngwg-addr-arch-v3-07.txt as a replacement for RFC 2374. draft-ietf-ipngwg-addr-arch-v3-07.txt quotes RFC 2374 in section 4. IANA considerations: INTERNET PROTOCOL VERSION 6 ADDRESS SPACE Global Unicast 001 1/8 [RFC2374] (However, [RFC2374] is not included in the references) So, is there a new version for RFC 2374 that deprecates TLA/NLA asignment rules or is just that reality is not following the RFCs? Regards, marcelo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 04:05:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SC53KL013139 for ; Thu, 28 Feb 2002 04:05:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SC52rw013138 for ipng-dist; Thu, 28 Feb 2002 04:05:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SC4wKL013125 for ; Thu, 28 Feb 2002 04:04:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01710 for ; Thu, 28 Feb 2002 04:04:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09386 for ; Thu, 28 Feb 2002 05:04:58 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17489; Thu, 28 Feb 2002 07:04:55 -0500 (EST) Message-Id: <200202281204.HAA17489@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-cellular-host-00.txt Date: Thu, 28 Feb 2002 07:04:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Minimum IPv6 Functionality for a Cellular Host Author(s) : J. Arkko et al. Filename : draft-ietf-ipv6-cellular-host-00.txt Pages : 26 Date : 27-Feb-02 As an increasing number of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, UMTS, and CDMA2000 terminals. Standardization organizations are also making IPv6 mandatory in their newest specifications, such as the IP multimedia terminals specified for UMTS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-cellular-host-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-cellular-host-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020227124605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-cellular-host-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-cellular-host-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227124605.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 04:28:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SCSdKL013206 for ; Thu, 28 Feb 2002 04:28:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SCSdtO013205 for ipng-dist; Thu, 28 Feb 2002 04:28:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SCSaKL013198 for ; Thu, 28 Feb 2002 04:28:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05725 for ; Thu, 28 Feb 2002 04:28:37 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09833 for ; Thu, 28 Feb 2002 05:28:35 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SCT9i28660 for ; Thu, 28 Feb 2002 14:29:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 14:28:34 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 14:28:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Thu, 28 Feb 2002 14:28:33 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F919E49@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHAUSTczlQQoS6QS6OjsUfp+vVL9QAAHWLg To: , <'deering@cisco.com'> Cc: X-OriginalArrivalTime: 28 Feb 2002 12:28:34.0044 (UTC) FILETIME=[70353BC0:01C1C053] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1SCSaKL013199 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! We "cellular host IPv6" draft authors believe that our draft http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-00.txt would be ready for wg last call. Bob and Steve, if there are no objections from the WG, could you please consider announcing last call for this draft? Thank You. On behalf of all the authors, Juha Wiljakka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 04:49:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SCnvKL013255 for ; Thu, 28 Feb 2002 04:49:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SCnveT013254 for ipng-dist; Thu, 28 Feb 2002 04:49:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SCnrKL013247 for ; Thu, 28 Feb 2002 04:49:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06491 for ; Thu, 28 Feb 2002 04:49:54 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17041 for ; Thu, 28 Feb 2002 05:49:52 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1SCnXk01529; Thu, 28 Feb 2002 13:49:33 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA01851; Thu, 28 Feb 2002 13:49:29 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1SCnNg83224; Thu, 28 Feb 2002 13:49:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202281249.g1SCnNg83224@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "marcelo bagnulo" cc: "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: About RFC 1887 In-reply-to: Your message of Thu, 28 Feb 2002 13:01:55 +0100. Date: Thu, 28 Feb 2002 13:49:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Tony, > De: Tony Hain [mailto:alh-ietf@tndh.net] > > The TLA/NLA rules are obsolete, as the RIRs are managing the space > without the TLA/NLA designations. See > draft-ietf-ipngwg-addr-arch-v3-07.txt as a replacement for RFC 2374. draft-ietf-ipngwg-addr-arch-v3-07.txt quotes RFC 2374 in section 4. IANA considerations: INTERNET PROTOCOL VERSION 6 ADDRESS SPACE Global Unicast 001 1/8 [RFC2374] (However, [RFC2374] is not included in the references) So, is there a new version for RFC 2374 that deprecates TLA/NLA asignment rules or is just that reality is not following the RFCs? => this was already discussed in the list: TLA/NLA should not be referenced (i.e. constrain) by the (future) DS document about addressing architecture. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 06:52:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SEqRKL013514 for ; Thu, 28 Feb 2002 06:52:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SEqR6B013513 for ipng-dist; Thu, 28 Feb 2002 06:52:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SEqNKL013506 for ; Thu, 28 Feb 2002 06:52:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02885 for ; Thu, 28 Feb 2002 06:52:23 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18931 for ; Thu, 28 Feb 2002 07:52:23 -0700 (MST) Received: from kenawang ([192.168.1.49]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA08895; Thu, 28 Feb 2002 06:51:56 -0800 (PST) Message-Id: <4.2.2.20020228094959.0207ca60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 28 Feb 2002 09:52:58 -0500 To: juha.wiljakka@nokia.com From: Margaret Wasserman Subject: Re: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Cc: In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F919E49@esebe005.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Juha, What type of last call are you proposing? Do you think that this document should become an informational RFC? Or do you think it should be on the standards track? It was my impression that we (the WG) were hoping to move towards a more general "node requirements" document, using this document as (one of) the input(s). Margaret At 07:28 AM 2/28/02 , juha.wiljakka@nokia.com wrote: > Hi! > >We "cellular host IPv6" draft authors believe that our draft > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-00.txt > >would be ready for wg last call. > >Bob and Steve, if there are no objections from the WG, >could you please consider announcing last call for this draft? > >Thank You. > >On behalf of all the authors, > Juha Wiljakka >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 09:34:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SHYiKL013922 for ; Thu, 28 Feb 2002 09:34:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SHYiLT013921 for ipng-dist; Thu, 28 Feb 2002 09:34:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SHYfKL013914 for ; Thu, 28 Feb 2002 09:34:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23499 for ; Thu, 28 Feb 2002 09:34:42 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23110 for ; Thu, 28 Feb 2002 10:34:41 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 28 Feb 2002 09:34:38 -0800 From: "Tony Hain" To: "Pekka Savola" , Cc: Subject: RE: RFC 3056 Date: Thu, 28 Feb 2002 09:34:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote: > > R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 > (relay router) > > > > Note: R1 is a pure 6to4 router; R2 and R3 are part of the > IPv4 cloud; R5 > > is a relay router. > > > > In the 6to4 model R1 and R4 need to have a 6to4 address. > From RFC 3056 I > > understand that these 6to4 addresses have to be configured on the > > interface between R1 and R2 (R4 and R3) respectively. I am > now puzzled > > between the following 2 observations: > > 1) I would also expect to have an IPv6 address configured > on R2's end of > > the R1-R2 interface. After all, only configuring an IPv6 > address on 1 of > > the routers connected to an interface would be a bit > strange? A similar > > remark holds for R3 on the R4-R3 interface. > > 2) However, no IPv6 address should be assigned to R2 (R3) > since R2 (R3) is > > only IPv4 capable? > > It's 6to4 _pseudo_ - interface :-). It's not assigned > (normally) on any > physical link. The only address you need between R1-R2 and > R3-R4 are IPv4 > addresses (from which, a 6to4 address may be derived from). > In case that was not clear; the IPv6 address on R1 & R4 are assigned to the pseudo interface that forms a logical point-to-point tunnel over the physical interfaces with IPv4 addresses. Another way to look at it is to consider the IPv4 components to be the logical equivalent of a multi-point Layer-2 network (like frame relay or ATM) so the IPv4 wrapper becomes just another framing wrapper for the 2002::/16 IPv6 subnet. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 09:57:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SHv1KL013979 for ; Thu, 28 Feb 2002 09:57:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SHv1WV013978 for ipng-dist; Thu, 28 Feb 2002 09:57:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SHuwKL013971 for ; Thu, 28 Feb 2002 09:56:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29146 for ; Thu, 28 Feb 2002 09:56:55 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04987 for ; Thu, 28 Feb 2002 10:56:49 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 28 Feb 2002 09:56:47 -0800 From: "Tony Hain" To: "marcelo bagnulo" , Subject: RE: About RFC 1887 Date: Thu, 28 Feb 2002 09:56:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk marcelo bagnulo wrote: > So, is there a new version for RFC 2374 that deprecates > TLA/NLA asignment > rules or is just that reality is not following the RFCs? The draft- series of documents are the work-in-progress for updating and adding to the RFC series. Your question hints at a belief that all RFCs contain rules and are consistent with each other. As you have found they are not consistent, and only the ones noted as STD have firm rules. Those documents in draft-standard or proposed-standard state contain rules we believe are going to become firm, but still need real-world development & deployment to verify they are correct. Look through RFC 2026 for a complete definition. In addition to documents that define standard rules, there are Informational documents like RFC 1887 that are intended to capture the current thinking on specific topics. In particular RFC 1887 represents some early thoughts about how address management might work from the perspective of 7 years ago when the sudden and dramatic rise in popularity of the Internet was just begining and excessive routing table growth was an overriding concern. While routing table growth is still a very real concern, we have collectively recognized that some of the earlier assumptions about policy enforcement were invalid, so there are new draft- series documents to update and bring the RFC series inline with current thoughts. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:15:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIFmKL014075 for ; Thu, 28 Feb 2002 10:15:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIFmXC014074 for ipng-dist; Thu, 28 Feb 2002 10:15:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIFjKL014067 for ; Thu, 28 Feb 2002 10:15:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03694 for ; Thu, 28 Feb 2002 10:15:46 -0800 (PST) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15761 for ; Thu, 28 Feb 2002 11:15:44 -0700 (MST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DBF2743128; Thu, 28 Feb 2002 19:15:43 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp03.uc3m.es (Postfix) with ESMTP id 9C80D99DE3; Thu, 28 Feb 2002 19:15:43 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id TAA26978; Thu, 28 Feb 2002 19:15:43 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA28519; Thu, 28 Feb 2002 19:15:39 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: "Tony Hain" , Subject: RE: About RFC 1887 Date: Thu, 28 Feb 2002 19:17:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Thanks for explaining this to me. > While routing table growth is still a > very real concern, we have collectively recognized that some of the > earlier assumptions about policy enforcement were invalid, so there are > new draft- series documents to update and bring the RFC series inline > with current thoughts. Where can I find current TLA/NLA allocation rules/ideas? (since RFC 2374 doesn´t represents current thoughts, right? and draft-ietf-ipngwg-addr-arch-v3-07.txt does not mention it) Regards, m -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:21:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SILZKL014121 for ; Thu, 28 Feb 2002 10:21:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SILZEg014120 for ipng-dist; Thu, 28 Feb 2002 10:21:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SILWKL014113 for ; Thu, 28 Feb 2002 10:21:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05110 for ; Thu, 28 Feb 2002 10:21:32 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17183 for ; Thu, 28 Feb 2002 11:21:31 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16gVB5-000Czl-00; Thu, 28 Feb 2002 10:21:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: "marcelo bagnulo" Cc: "Tony Hain" , Subject: RE: About RFC 1887 References: Message-Id: Date: Thu, 28 Feb 2002 10:21:15 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Where can I find current TLA/NLA allocation rules/ideas? (since RFC 2374 > doesn´t represents current thoughts, right? and > draft-ietf-ipngwg-addr-arch-v3-07.txt does not mention it) as the ietf does not allocate address space, probably not around here. you might try places where addresses are allocated, i.e. the registries. there is 'active discussion' going on over in the registry community. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:38:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIc4KL014174 for ; Thu, 28 Feb 2002 10:38:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIc4Sk014173 for ipng-dist; Thu, 28 Feb 2002 10:38:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIc1KL014166 for ; Thu, 28 Feb 2002 10:38:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10174 for ; Thu, 28 Feb 2002 10:38:01 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08700 for ; Thu, 28 Feb 2002 11:38:00 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 95ADF4313E; Thu, 28 Feb 2002 19:37:59 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id E3BC899E5A; Thu, 28 Feb 2002 19:37:58 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id TAA30966; Thu, 28 Feb 2002 19:37:52 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA06067; Thu, 28 Feb 2002 19:37:51 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: "Randy Bush" Cc: "Tony Hain" , Subject: RE: About RFC 1887 Date: Thu, 28 Feb 2002 19:39:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as the ietf does not allocate address space, probably not around > here. you But the IETF does reccomend assignment policies and rules, right? such as RFC 2374? > might try places where addresses are allocated, i.e. the > registries. there > is 'active discussion' going on over in the registry community. Thanks,m -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:45:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIjRKL014238 for ; Thu, 28 Feb 2002 10:45:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIjQdA014237 for ipng-dist; Thu, 28 Feb 2002 10:45:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIjNKL014230 for ; Thu, 28 Feb 2002 10:45:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14344 for ; Thu, 28 Feb 2002 10:45:19 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29511 for ; Thu, 28 Feb 2002 11:45:19 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16gVYH-000Dge-00; Thu, 28 Feb 2002 10:45:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "marcelo bagnulo" Cc: "Tony Hain" , Subject: RE: About RFC 1887 References: Message-Id: Date: Thu, 28 Feb 2002 10:45:13 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> as the ietf does not allocate address space, probably not around >> here. > But the IETF does reccomend assignment policies and rules, right? > such as RFC 2374? as folk here have been repeatedly saying, that is being replaced. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:47:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIlqKL014299 for ; Thu, 28 Feb 2002 10:47:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIlp7q014297 for ipng-dist; Thu, 28 Feb 2002 10:47:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIlmKL014286 for ; Thu, 28 Feb 2002 10:47:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05845 for ; Thu, 28 Feb 2002 10:47:48 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01253 for ; Thu, 28 Feb 2002 11:47:43 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1SIlfw22049; Thu, 28 Feb 2002 10:47:41 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACT37415; Thu, 28 Feb 2002 10:47:32 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: <20020212061255.27232.qmail@mailweb15.rediffmail.com> Date: Thu, 28 Feb 2002 10:47:40 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: Query regarding loopback interface Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:39 PM +0900 2/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> Steve Deering said: > > > The loopback link does not require a link-local address. If you have > > virtual links that can have more than one node attached (e.g., some > > people refer to an IP tunnel as a virtual link), those links will > > need link-local addresses for the (virtually) attached nodes. > >This is quite reasonable, but seems to contradict a requirement in the >address architecture draft: > > All interfaces are required to have at least one link-local unicast > address (see section 2.8 for additional required addresses). >(draft-ietf-ipngwg-addr-arch-v3-07.txt, Section 2.1) In the scoped addresss architecture draft, we say: The IPv6 unicast loopback address, ::1, is treated as having link- local scope within an imaginary link to which a virtual "loopback interface" is attached. effectively saying that the ::1 loopback address is a special-case link-local address. >We may have to clarify this point before the draft is in an RFC >status. I agree. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 10:51:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIpYKL014334 for ; Thu, 28 Feb 2002 10:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIpYqU014333 for ipng-dist; Thu, 28 Feb 2002 10:51:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIpVKL014326 for ; Thu, 28 Feb 2002 10:51:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15156 for ; Thu, 28 Feb 2002 10:51:26 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16989 for ; Thu, 28 Feb 2002 10:51:26 -0800 (PST) Subject: RE: About RFC 1887 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 28 Feb 2002 10:51:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C3B8@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About RFC 1887 Thread-Index: AcHAhGCJjORm+OcQRnSAkd1xtW9ZcQABGE9g From: "Michel Py" To: "Marcelo Bagnulo" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1SIpVKL014327 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Where can I find current TLA/NLA allocation rules/ideas? > (since RFC 2374 doesn´t represents current thoughts, right? > and draft-ietf-ipngwg-addr-arch-v3-07.txt does not mention it) A starting point here: http://www.arin.net/regserv/ipv6/ipv6guidelines.html RIPE would be where to look for Europe. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 11:01:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJ17KL014383 for ; Thu, 28 Feb 2002 11:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SJ17lr014382 for ipng-dist; Thu, 28 Feb 2002 11:01:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJ14KL014375 for ; Thu, 28 Feb 2002 11:01:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15428 for ; Thu, 28 Feb 2002 11:01:04 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10292 for ; Thu, 28 Feb 2002 12:01:03 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 28 Feb 2002 11:00:58 -0800 From: "Tony Hain" To: "marcelo bagnulo" , "Randy Bush" Cc: Subject: RE: About RFC 1887 Date: Thu, 28 Feb 2002 11:00:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: > as the ietf does not allocate address space, probably not > around here. you > might try places where addresses are allocated, i.e. the > registries. there > is 'active discussion' going on over in the registry community. Specific pointers include: http://www.arin.net/announcements/2001_policy_discuss.html#policy4 & - Further work towards consensus on a global policy will continue via discussions on the global IPv6 mailing list: . marcelo bagnulo wrote: > But the IETF does reccomend assignment policies and rules, > right? such as > RFC 2374? The IETF will give architectural guidance on what makes sense, and occasionally (like RFC 2374) will overstep the boundary between architecture and policy. When that error is recognized the documents will be updated to reflect the necessary changes. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 22:29:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g216TAKL015702 for ; Thu, 28 Feb 2002 22:29:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g216T9nn015701 for ipng-dist; Thu, 28 Feb 2002 22:29:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g216T7KL015694 for ; Thu, 28 Feb 2002 22:29:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10014 for ; Thu, 28 Feb 2002 22:29:08 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26323 for ; Thu, 28 Feb 2002 23:29:06 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g216Sr325739; Fri, 1 Mar 2002 07:28:53 +0100 (MET) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 1 Mar 2002 07:28:50 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/01/2002 07:28:53, Serialize complete at 03/01/2002 07:28:53 Content-Type: multipart/alternative; boundary="=_alternative 00239965C1256B6F_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 00239965C1256B6F_= Content-Type: text/plain; charset="us-ascii" Hi Pekka, Tony, Thanks for your replies. I do have 1 question with respect to the pseudo-interfaces. For **configured** tunnels the ifIndex for the corresponding pseudo interface is created as a by-product of row creation in the tunnelConfigTable (RFC 2667). However, for automatic tunnels no row is created in the tunnelConfigTable. But what is then the trigger to create an ifIndex for a pseudo interface for an **automatic** tunnel? Thanks for any clarifications you can provide. Best regards, Francis. ==================== Pekka Savola 28/02/2002 11:21 To: Francis ARTS/BE/ALCATEL@ALCATEL cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote: > R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 (relay router) > > Note: R1 is a pure 6to4 router; R2 and R3 are part of the IPv4 cloud; R5 > is a relay router. > > In the 6to4 model R1 and R4 need to have a 6to4 address. From RFC 3056 I > understand that these 6to4 addresses have to be configured on the > interface between R1 and R2 (R4 and R3) respectively. I am now puzzled > between the following 2 observations: > 1) I would also expect to have an IPv6 address configured on R2's end of > the R1-R2 interface. After all, only configuring an IPv6 address on 1 of > the routers connected to an interface would be a bit strange? A similar > remark holds for R3 on the R4-R3 interface. > 2) However, no IPv6 address should be assigned to R2 (R3) since R2 (R3) is > only IPv4 capable? It's 6to4 _pseudo_ - interface :-). It's not assigned (normally) on any physical link. The only address you need between R1-R2 and R3-R4 are IPv4 addresses (from which, a 6to4 address may be derived from). HTH, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- Tony Hain wrote: Pekka Savola wrote: > On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote: > > R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 > (relay router) > > > > Note: R1 is a pure 6to4 router; R2 and R3 are part of the > IPv4 cloud; R5 > > is a relay router. > > > > In the 6to4 model R1 and R4 need to have a 6to4 address. > From RFC 3056 I > > understand that these 6to4 addresses have to be configured on the > > interface between R1 and R2 (R4 and R3) respectively. I am > now puzzled > > between the following 2 observations: > > 1) I would also expect to have an IPv6 address configured > on R2's end of > > the R1-R2 interface. After all, only configuring an IPv6 > address on 1 of > > the routers connected to an interface would be a bit > strange? A similar > > remark holds for R3 on the R4-R3 interface. > > 2) However, no IPv6 address should be assigned to R2 (R3) > since R2 (R3) is > > only IPv4 capable? > > It's 6to4 _pseudo_ - interface :-). It's not assigned > (normally) on any > physical link. The only address you need between R1-R2 and > R3-R4 are IPv4 > addresses (from which, a 6to4 address may be derived from). > In case that was not clear; the IPv6 address on R1 & R4 are assigned to the pseudo interface that forms a logical point-to-point tunnel over the physical interfaces with IPv4 addresses. Another way to look at it is to consider the IPv4 components to be the logical equivalent of a multi-point Layer-2 network (like frame relay or ATM) so the IPv4 wrapper becomes just another framing wrapper for the 2002::/16 IPv6 subnet. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --=_alternative 00239965C1256B6F_= Content-Type: text/html; charset="us-ascii"
Hi Pekka, Tony,

Thanks for your replies. I do have 1 question with respect to the pseudo-interfaces. For **configured** tunnels the ifIndex for the corresponding pseudo interface is created as a by-product of row creation in  the tunnelConfigTable (RFC 2667). However, for automatic tunnels no row is created in the tunnelConfigTable. But what is then the trigger to create an ifIndex for a pseudo interface for an **automatic** tunnel?

Thanks for any clarifications you can provide.

Best regards,

        Francis.

====================



Pekka Savola <pekkas@netcore.fi>

28/02/2002 11:21

       
        To:        Francis ARTS/BE/ALCATEL@ALCATEL
        cc:        ipng@sunroof.eng.sun.com
        Subject:        Re: RFC 3056



On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote:
>         R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4 (relay router)
>
> Note: R1 is a pure 6to4 router; R2 and R3 are part of the IPv4 cloud; R5
> is a relay router.
>
> In the 6to4 model R1 and R4 need to have a 6to4 address. From RFC 3056 I
> understand that these 6to4 addresses have to be configured on the
> interface between R1 and R2 (R4 and R3) respectively. I am now puzzled
> between the following 2 observations:
> 1) I would also expect to have an IPv6 address configured on R2's end of
> the R1-R2 interface. After all, only configuring an IPv6 address on 1 of
> the routers connected to an interface would be a bit strange? A similar
> remark holds for R3 on the R4-R3 interface.
> 2) However, no IPv6 address should be assigned to R2 (R3) since R2 (R3) is
> only IPv4 capable?

It's 6to4 _pseudo_ - interface :-).  It's not assigned (normally) on any
physical link.  The only address you need between R1-R2 and R3-R4 are IPv4
addresses (from which, a 6to4 address may be derived from).

HTH,

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


Tony Hain wrote:

Pekka Savola wrote:
> On Thu, 28 Feb 2002 francis.arts@alcatel.be wrote:
> >         R1 (6to4 router) -- R2 (IPv4) -- R3 (IPv4) -- R4
> (relay router)
> >
> > Note: R1 is a pure 6to4 router; R2 and R3 are part of the
> IPv4 cloud; R5
> > is a relay router.
> >
> > In the 6to4 model R1 and R4 need to have a 6to4 address.
> From RFC 3056 I
> > understand that these 6to4 addresses have to be configured on the
> > interface between R1 and R2 (R4 and R3) respectively. I am
> now puzzled
> > between the following 2 observations:
> > 1) I would also expect to have an IPv6 address configured
> on R2's end of
> > the R1-R2 interface. After all, only configuring an IPv6
> address on 1 of
> > the routers connected to an interface would be a bit
> strange? A similar
> > remark holds for R3 on the R4-R3 interface.
> > 2) However, no IPv6 address should be assigned to R2 (R3)
> since R2 (R3) is
> > only IPv4 capable?
>
> It's 6to4 _pseudo_ - interface :-).  It's not assigned
> (normally) on any
> physical link.  The only address you need between R1-R2 and
> R3-R4 are IPv4
> addresses (from which, a 6to4 address may be derived from).
>

In case that was not clear; the IPv6 address on R1 & R4 are assigned to
the pseudo interface that forms a logical point-to-point tunnel over the
physical interfaces with IPv4 addresses.

Another way to look at it is to consider the IPv4 components to be the
logical equivalent of a multi-point Layer-2 network (like frame relay or
ATM) so the IPv4 wrapper becomes just another framing wrapper for the
2002::/16 IPv6 subnet.

Tony


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--=_alternative 00239965C1256B6F_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 28 23:17:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g217HKKL015777 for ; Thu, 28 Feb 2002 23:17:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g217HKHi015776 for ipng-dist; Thu, 28 Feb 2002 23:17:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g217HHKL015769 for ; Thu, 28 Feb 2002 23:17:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03086 for ; Thu, 28 Feb 2002 23:17:19 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10089 for ; Thu, 28 Feb 2002 23:17:17 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g217HAf02451; Fri, 1 Mar 2002 09:17:10 +0200 Date: Fri, 1 Mar 2002 09:17:09 +0200 (EET) From: Pekka Savola To: francis.arts@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Mar 2002 francis.arts@alcatel.be wrote: > Thanks for your replies. I do have 1 question with respect to the > pseudo-interfaces. For **configured** tunnels the ifIndex for the > corresponding pseudo interface is created as a by-product of row > creation in the tunnelConfigTable (RFC 2667). However, for automatic > tunnels no row is created in the tunnelConfigTable. But what is then the > trigger to create an ifIndex for a pseudo interface for an **automatic** > tunnel? > > Thanks for any clarifications you can provide. Well, if no such thing is created, I think that's an implementation issue. Anyway, RFC3056 is more of a ngtrans than ipng. I don't see why you couldn't create an entry for automatic tunnels, the only thing to watch out for is that tunnelConfigRemoteAddress is zero. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------