From owner-ipng@sunroof.eng.sun.com Sat Feb 1 00:41:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h118f5Qb000553; Sat, 1 Feb 2003 00:41:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h118f5P0000552; Sat, 1 Feb 2003 00:41:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h118f2Qb000545 for ; Sat, 1 Feb 2003 00:41:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h118fAVL012112 for ; Sat, 1 Feb 2003 00:41:10 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22492 for ; Sat, 1 Feb 2003 00:41:05 -0800 (PST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9CCFC137F09; Sat, 1 Feb 2003 00:41:04 -0800 (PST) Date: Sat, 1 Feb 2003 00:41:00 -0800 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Dan Lanciani From: David Conrad In-Reply-To: <200302010727.CAA25994@ss10.danlan.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, On Friday, January 31, 2003, at 11:27 PM, Dan Lanciani wrote: > |Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?. > Sure, this has been proposed before, but I think the main complaint was > that 64 bits is no longer enough for the wasteful allocation policies > we > have adopted. Given there is no need for hierarchy, there is no need for wasteful allocation policies (the end point addresses could be allocated sequentially FCFS or even randomly). I have a bit of trouble believing 18,446,744,073,709,551,616 sequentially assigned addresses would be insufficient for "the foreseeable future". > |No translation would be necessary. > You have to translate somewhere, if not at the bottom of the host's > stack > then at what you are calling edge routers. I guess it is a question of terminology: there is no translation done on the end point identifiers, thus they can be encoded into higher layer protocols (e.g., ftp) without need of NAT gymnastics. The only "translation" done would be the zeroing out of the high order 8 bytes on reception at the destination edge router which would presumably be faster than a table lookup. > |> With a little care, multi-homing could be supported. > |Multi-homing would be trivial. > Some care would be required to get failover to work. This isn't > completely > trivial, but it need not be a big deal. I would assume the edge router would 'know' the reachability of the prefixes returned by the DNS query allowing for failover to be handled the same way it is handled today (more or less). Simple AS hop games can be played to pick the 'best'. > |The lower 64 bits of the destination would be put into an > |in-addr.arpa-like tree, > I like my specialized mapping service, but sure... I'd honestly be happy with either. The advantage I see in the DNS is that it exists, is relatively well understood, and has the necessary attributes (global scalability, security (if you believe DNSSEC will ever be deployed), and caching). However, we have learned a lot about what the DNS got wrong and a new mapping service could allow us to finally put a bullet in DNS's head... > I proposed to short-circuit the timeout by having nodes try where > possible > to give a hint to known peers that a renumbering event had occurred. > This > can also be handled either at the end points or at the edge routers. Right (I think -- I had suggested the edge routers act as forwarding agents for a TTL, is this what you mean by short-circuiting?) In any event, from my perspective the big problem with this approach, regardless of whether the DNS is used or not, is the need for edge routers at both ends to be involved. This results in a chicken and egg problem that I'm not sure how to get around. Oh yeah, and traceroute from the end points would be useless. However, this (and similar) approaches have the advantage that we continue to use known technology (CIDR,BGP4+,etc) in the core where it matters... Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 1 09:35:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11HZLQb001606; Sat, 1 Feb 2003 09:35:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h11HZLZR001605; Sat, 1 Feb 2003 09:35:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11HZIQb001598 for ; Sat, 1 Feb 2003 09:35:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h11HZSVK025270 for ; Sat, 1 Feb 2003 09:35:28 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06054 for ; Sat, 1 Feb 2003 09:35:21 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id MAA27326; Sat, 1 Feb 2003 12:35:17 -0500 (EST) Date: Sat, 1 Feb 2003 12:35:17 -0500 (EST) From: Dan Lanciani Message-Id: <200302011735.MAA27326@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad wrote: |On Friday, January 31, 2003, at 11:27 PM, Dan Lanciani wrote: |> |Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?. |> Sure, this has been proposed before, but I think the main complaint was |> that 64 bits is no longer enough for the wasteful allocation policies |> we |> have adopted. | |Given there is no need for hierarchy, there is no need for wasteful |allocation policies (the end point addresses could be allocated |sequentially FCFS or even randomly). I have a bit of trouble believing |18,446,744,073,709,551,616 sequentially assigned addresses would be |insufficient for "the foreseeable future". I was actually referring to the practice of inserting 48-bit (or even 64-bit) hardware identifiers into the address in the name of easy configuration. |> |No translation would be necessary. |> You have to translate somewhere, if not at the bottom of the host's |> stack |> then at what you are calling edge routers. | |I guess it is a question of terminology: there is no translation done |on the end point identifiers, thus they can be encoded into higher |layer protocols (e.g., ftp) without need of NAT gymnastics. The only |"translation" done would be the zeroing out of the high order 8 bytes |on reception at the destination edge router which would presumably be |faster than a table lookup. Even if you don't consider the zeroing a translation (and I would probably debate this if it made any difference), the mapping of (0, 64-bit identifier) to (64-bit locator, 64-bit identifier) is certainly a translation as much as the mapping of (128-bit identifier) to (128-bit locator). The property of being able to encode the identifier into higher-layer protocols without the need for NAT gymnastics is a function of hiding the translation from all the higher layers, not of the simplicity of the translation function. My proposal also hides the locator and thus has the same property. |> |> With a little care, multi-homing could be supported. |> |Multi-homing would be trivial. |> Some care would be required to get failover to work. This isn't |> completely |> trivial, but it need not be a big deal. | |I would assume the edge router would 'know' the reachability of the |prefixes returned by the DNS query allowing for failover to be handled |the same way it is handled today (more or less). Simple AS hop games |can be played to pick the 'best'. I would not want to depend on the edge router's having that kind of knowledge of the locator routing system just to make multi-homing work for other sites. (It would be one thing to require multi-homed sites to do this, but you are talking about making everybody do it.) I think it would be better to explicitly track only those targets that are being used. Hopefully icmp messages could do most of the work along with something akin to stale route discovery. |> I proposed to short-circuit the timeout by having nodes try where |> possible |> to give a hint to known peers that a renumbering event had occurred. |> This |> can also be handled either at the end points or at the edge routers. | |Right (I think -- I had suggested the edge routers act as forwarding |agents for a TTL, is this what you mean by short-circuiting?) I'm not sure what you meant by forwarding. I simply meant that a node or edge router that is renumbered can send an alert to its known peers suggesting that they dump their cached data even though its TTL has not expired. |In any event, from my perspective the big problem with this approach, |regardless of whether the DNS is used or not, is the need for edge |routers at both ends to be involved. This results in a chicken and egg |problem that I'm not sure how to get around. My proposal can definitely work (and was originally intended to work) directly on end nodes. It can be pushed into edge routers as well, but it doesn't have to be. But it isn't obvious to me why your version can't work on an end node too. |Oh yeah, and traceroute |from the end points would be useless. If the translation happens at the end nodes I would obviously propose an escape mechanism in the API to deal with locators instead of identifiers. Obviously we would want to discourage use of this escape by other than debugging programs. :) |However, this (and similar) approaches have the advantage that we |continue to use known technology (CIDR,BGP4+,etc) in the core where it |matters... That advantage makes for a good thought experiment, i.e., to show anyone with an open mind that it can be done. Whether we really want to help perpetuate the current archaic routing system by building a layer like this is still open to debate. Clearly adding a layer is better than doing nothing; however, I'd like to think that we can ascertain a pure routing solution that is isomorphic to the split solution. Again, we are really talking about source routing and there are quite a few ways to implement source routing. 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 Sat Feb 1 11:02:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11J28Qb001811; Sat, 1 Feb 2003 11:02:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h11J28Cg001810; Sat, 1 Feb 2003 11:02:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11J25Qb001803 for ; Sat, 1 Feb 2003 11:02:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h11J2FVK009980 for ; Sat, 1 Feb 2003 11:02:15 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01324 for ; Sat, 1 Feb 2003 12:02:09 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA27847 for ; Sat, 1 Feb 2003 19:02:08 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h11J258A012492 for ; Sat, 1 Feb 2003 19:02:05 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h11J24U12156 for ipng@sunroof.eng.sun.com; Sat, 1 Feb 2003 19:02:04 GMT Date: Sat, 1 Feb 2003 19:02:04 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt Message-ID: <20030201190204.GB12078@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <4.3.2.7.2.20030131152153.0298a988@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Feb 01, 2003 at 01:54:58AM +0200, Pekka Savola wrote: > > I, for one, am very adamantly against reserving 2000:0001::/32. That > wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first > parts of it are needed). An extremely bad idea, IMO. I'd recommend taking > something from 2001, like 2001:0001::/32 or 2001:FFFF::/32. Well, looks like 2000:0001::/32 is now what sites running IPv6 NAT will use inside their networks... won't be long :( 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 Sat Feb 1 11:54:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11JsSQb002027; Sat, 1 Feb 2003 11:54:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h11JsS4x002026; Sat, 1 Feb 2003 11:54:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11JsOQb002019 for ; Sat, 1 Feb 2003 11:54:25 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h11JsZVL002949 for ; Sat, 1 Feb 2003 11:54:35 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17656 for ; Sat, 1 Feb 2003 11:54:29 -0800 (PST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9F64E137F09; Sat, 1 Feb 2003 11:54:28 -0800 (PST) Date: Sat, 1 Feb 2003 11:54:27 -0800 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Dan Lanciani From: David Conrad In-Reply-To: <200302011735.MAA27326@ss10.danlan.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote: > I was actually referring to the practice of inserting 48-bit (or even > 64-bit) > hardware identifiers into the address in the name of easy > configuration. One allocation mechanism is pretty much as good as any other. Doesn't matter how those 48 or 64 bit numbers are allocated, the EUI registry would be fine. What matters is there is a separation and a mapping between those identifiers and locators. > Even if you don't consider the zeroing a translation (and I would > probably > debate this if it made any difference), the mapping of (0, 64-bit > identifier) > to (64-bit locator, 64-bit identifier) is certainly a translation as > much > as the mapping of (128-bit identifier) to (128-bit locator). I agree that the terminology doesn't matter (I actually viewed it more along the lines of pushing a locator onto the address at ingress, popping it off at egress -- I liked the x-kernel work of long ago). What is important is the separation of the locator from the end point and the ability to map between the two. > My proposal also hides the locator and thus has the same property. Yup. I was merely making the assumption that zero'ing would be faster than table lookup and copying. However, given this is an edge function, it probably doesn't matter all that much. > I would not want to depend on the edge router's having that kind of > knowledge > of the locator routing system just to make multi-homing work for other > sites. Hmmm. Multiple ways to solve this, of course. E.g.: the source edge router does a lookup, gets back a bunch of locators. A naive implementation could simply pick one and forward to the core via default. Getting back a network unreachable could trigger the naive implementation to pick a different locator. The more elaborate the edge router gets in terms of routing system knowledge, the more effective the multi-homing would be. > I'm not sure what you meant by forwarding. The old destination edge router gets a packet for an end point identifier that has left the network the old edge router is responsible for. The old edge router does a lookup of the destination identifier, gets the new locator (if it doesn't already have it), and forwards to the new edge router. It would need to do this for the TTL of the old locator. This is why I believe this approach would work with mobility -- in this context, mobility is just a more dynamic form of renumbering. Yes there may be security issues here in the general case -- need to think about it more. > My proposal can definitely work (and was originally intended to work) > directly > on end nodes. It can be pushed into edge routers as well, but it > doesn't have > to be. But it isn't obvious to me why your version can't work on an > end node > too. It would. The reason I favor the edge router approach is that I wanted something that would work with IPv4 as a transition aide... > Whether we really want to help perpetuate > the current archaic routing system by building a layer like this is > still open > to debate. Clearly adding a layer is better than doing nothing; > however, I'd > like to think that we can ascertain a pure routing solution that is > isomorphic > to the split solution. Baby steps... Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 1 12:51:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11KpPQb002206; Sat, 1 Feb 2003 12:51:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h11KpPSp002205; Sat, 1 Feb 2003 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h11KpLQb002198 for ; Sat, 1 Feb 2003 12:51:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h11KpVVK028648 for ; Sat, 1 Feb 2003 12:51:32 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21713 for ; Sat, 1 Feb 2003 13:51:25 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA27853; Sat, 1 Feb 2003 15:51:21 -0500 (EST) Date: Sat, 1 Feb 2003 15:51:21 -0500 (EST) From: Dan Lanciani Message-Id: <200302012051.PAA27853@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad wrote: |On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote: |> I was actually referring to the practice of inserting 48-bit (or even |> 64-bit) |> hardware identifiers into the address in the name of easy |> configuration. | |One allocation mechanism is pretty much as good as any other. Doesn't |matter how those 48 or 64 bit numbers are allocated, the EUI registry |would be fine. That isn't clear. There are certainly cases where we will want to number an interface for which we do not already have an EUI from the hardware. If the entire identifier space is already taken up with EUIs then there is no room for someone to get a block of identifiers for non-EUI applications. I admit I haven't looked into this; what does it take to get an EUI-64 allocation? I assume that to get any EUI-48 space you still have to buy an OUI at a fairly high price (or else buy old Ethernet cards to hold as tokens). |> I would not want to depend on the edge router's having that kind of |> knowledge |> of the locator routing system just to make multi-homing work for other |> sites. | |Hmmm. Multiple ways to solve this, of course. E.g.: the source edge |router does a lookup, gets back a bunch of locators. A naive |implementation could simply pick one and forward to the core via |default. Getting back a network unreachable could trigger the naive |implementation to pick a different locator. The more elaborate the |edge router gets in terms of routing system knowledge, the more |effective the multi-homing would be. Again, I'm not thrilled with making the effectiveness of multi-homing depend on the participation of other sites' routers in the low-level routing (locator) system. I would prefer to add more at the identifier level, but this is really a minor quibble. |> I'm not sure what you meant by forwarding. | |The old destination edge router gets a packet for an end point |identifier that has left the network the old edge router is responsible |for. The old edge router does a lookup of the destination identifier, |gets the new locator (if it doesn't already have it), and forwards to |the new edge router. It would need to do this for the TTL of the old |locator. Yes, definitely not what I meant by short-circuiting. :) |It would. The reason I favor the edge router approach is that I wanted |something that would work with IPv4 as a transition aide... I'm still not sure I see why it wouldn't work. |> Whether we really want to help perpetuate |> the current archaic routing system by building a layer like this is |> still open |> to debate. Clearly adding a layer is better than doing nothing; |> however, I'd |> like to think that we can ascertain a pure routing solution that is |> isomorphic |> to the split solution. | |Baby steps... Perhaps, but this is really what got us into the mess we are in today. What was meant as a crutch to keep memory-address-bit-deficient hardware viable for a few extra months/years has become a serious dependency problem. By turning addresses into almost-routes aggregation has allowed routing protocols that were obsolete years ago to remain in use, but end users pay the terrible price of having their addresses tied to topology. Like any addiction, this problem will only get worse as we continue to feed it. So, yes, I'm all for a translation layer if it is the best that we can do and if we can do it at all. But since we almost certainly can't do it all in the face of current politics, I might as well dream about fixing routing... 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 Mon Feb 3 04:31:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13CViQb005091; Mon, 3 Feb 2003 04:31:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13CVh83005090; Mon, 3 Feb 2003 04:31:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13CVeQb005083 for ; Mon, 3 Feb 2003 04:31:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13CVmVL006229 for ; Mon, 3 Feb 2003 04:31:48 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09953 for ; Mon, 3 Feb 2003 04:31:42 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 91BAB4B23; Mon, 3 Feb 2003 21:31:35 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Fri, 31 Jan 2003 19:40:19 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt From: itojun@iijlab.net Date: Mon, 03 Feb 2003 21:31:35 +0900 Message-Id: <20030203123135.91BAB4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >3.0 IANA Considerations > > The following prefix is reserved for use in documentation and MUST > NOT be assigned to any operational IPv6 nodes: > > 2000:0001::/32 > >==> I do not understand why this reservation has been made; I see zero >technical reason for it -- and it would prevent the use of the full >2000::/16 for something else. > >I'd rather reserve a documentation prefix somewhere else, and in some >other, _separate_ internet-draft. there have been multiple attempts made to reserve address space for documentation, including: draft-itojun-ipv6-local-experiment-00.txt draft-itojun-ipv6-local-experiment-01.txt draft-blanchet-ngtrans-exampleaddr-00.txt draft-blanchet-ngtrans-exampleaddr-01.txt i dunno why the attempt is suddenly revisited out of blue. this has to be discussed in a separate internet draft (i agree with Pekka), on: - validity of the address reservation itself - what address should we use? - for what purpose? (no more private address, please) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 3 04:51:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13CpjQb005266; Mon, 3 Feb 2003 04:51:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13CpjFx005265; Mon, 3 Feb 2003 04:51:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13CpfQb005258 for ; Mon, 3 Feb 2003 04:51:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13CpnVL008878 for ; Mon, 3 Feb 2003 04:51:49 -0800 (PST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17627 for ; Mon, 3 Feb 2003 05:51:42 -0700 (MST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h13CpTsV003779 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 3 Feb 2003 13:51:29 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h13CpTAa029801 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 3 Feb 2003 13:51:29 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h13CpSDv029797; Mon, 3 Feb 2003 13:51:28 +0100 Date: Mon, 3 Feb 2003 13:51:28 +0100 Message-Id: <200302031251.h13CpSDv029797@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: heard@pobox.com CC: ipng@sunroof.eng.sun.com In-reply-to: (heard@pobox.com) Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2) References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> C M Heard writes: Mike> I saw that when I went through the archived e-mail. Do you Mike> think that having an OCTET STRING-based policy selector (in Mike> addition to destination prefix/prefix length and next hop) as I Mike> suggested can provide the required flexibility? As far as I can Mike> see it does, although it might not be the most convenient way. Since forwarding architectures tend to look pretty different, I guess we can't do more than using some opaque identifier - whether that is an OBJECT IDENTIFIER, an INTEGER will some smart numbering scheme (similar to SnmpSecurityModel), or an OCTET STRING does not really make a big difference to me. The problem is that mgmt applications either understand the semantics of a particular implementation or they will have to guess or ignore some rows. So from an interoperability point of view, all this is only little better than not having such an index component. Perhaps we really need a "remote operations" MIB where you just send a fragment of an IP header and you get back the next hop. ;-) /js -- Juergen Schoenwaelder -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 3 05:28:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13DSdQb005596; Mon, 3 Feb 2003 05:28:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13DSdn6005595; Mon, 3 Feb 2003 05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13DSaQb005588 for ; Mon, 3 Feb 2003 05:28:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13DSiVK028434 for ; Mon, 3 Feb 2003 05:28:44 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15831 for ; Mon, 3 Feb 2003 06:28:38 -0700 (MST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h13DVDe13468 for ; Mon, 3 Feb 2003 15:31:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Feb 2003 15:28:37 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 15:28:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 15:28:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node Requirements and 3041 Date: Mon, 3 Feb 2003 15:28:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements and 3041 Thread-Index: AcLIPs6+5rVu2VArSouHKgFqE67KYwDSTHEg To: Cc: , , , X-OriginalArrivalTime: 03 Feb 2003 13:28:36.0479 (UTC) FILETIME=[27E030F0:01C2CB88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h13DSaQb005589 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Samita, > In the last sentence, did you mean to say that the node should have a > configuration knob whether to turn on privacy extension behavior ? > > If so, would it be clearer to say something like the following ? > > 'It is recommended that the node be configurable to turn on/off > the privacy extension for stateless address autoconfiguration, when > it is implemented.' It should be something like that, but I think Alain was suggesting that a node-based policy would not be sufficient. It should be at least application based policy, since different applications will not work with 3041 addresses. br, John > Otherwise, as Alain mentioned, it's up to the application and > system-default > configuration to use temporary or public address for a connection. > We have discussed about possible socket API solution for > source address > selection on per-socket basis. A draft is in plan for that. > > -Samita > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 3 07:04:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13F4iQb005924; Mon, 3 Feb 2003 07:04:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13F4ib6005923; Mon, 3 Feb 2003 07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13F4fQb005916 for ; Mon, 3 Feb 2003 07:04:41 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13F4nVK018441 for ; Mon, 3 Feb 2003 07:04:49 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10020 for ; Mon, 3 Feb 2003 07:04:41 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13F3UH3022834; Mon, 3 Feb 2003 16:03:50 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13F3DJ3258782; Mon, 3 Feb 2003 16:03:13 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40094 from ; Mon, 3 Feb 2003 16:03:11 +0100 Message-Id: <3E3E8481.ECBFB4BA@hursley.ibm.com> Date: Mon, 03 Feb 2003 16:02:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Bob Hinden Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt References: <4.3.2.7.2.20030131152153.0298a988@mailhost.iprg.nokia.com> <4.3.2.7.2.20030131163516.0270bcd0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: ... > > > >I, for one, am very adamantly against reserving 2000:0001::/32. That > >wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first > >parts of it are needed). An extremely bad idea, IMO. I'd recommend taking > >something from 2001, like 2001:0001::/32 or 2001:FFFF::/32. > > I viewed it as opening up the rest of the 2000::/16 prefix for /32 > allocations. Currently all of 2000::/16 is reserved in > > http://www.iana.org/assignments/ipv6-tla-assignments > > I guess it depends on how one looks at it. > > >And this kind of "which one is the right block to reserve" discussions > >could delay the other parts of the draft, which was my main motivation for > >keeping it outside of this one. > > Lets try to avoid a lengthily discussion on this. I think the w.g. has > more pressing issues. If others have strong feeling on this, I am happy to > change it. Or remove it. It's clear we won't converge rapidly on a specific choice, so I'd suggest removing it so we can go quickly to a Last Call on this draft. Actually, we could simply ask IANA to reserve a /32 prefix for documentation purposes; it doesn't need an RFC. 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 Mon Feb 3 07:12:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13FCZQb006045; Mon, 3 Feb 2003 07:12:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13FCYu2006042; Mon, 3 Feb 2003 07:12:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13FCVQb006035 for ; Mon, 3 Feb 2003 07:12:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13FCeVL000347 for ; Mon, 3 Feb 2003 07:12:40 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18573 for ; Mon, 3 Feb 2003 08:12:34 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13FCLH3041190; Mon, 3 Feb 2003 16:12:24 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13FCJAl074546; Mon, 3 Feb 2003 16:12:19 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13528 from ; Mon, 3 Feb 2003 16:12:18 +0100 Message-Id: <3E3E86A3.3B209994@hursley.ibm.com> Date: Mon, 03 Feb 2003 16:11:31 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: David Conrad Cc: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses References: <9963C6AE-354D-11D7-BA7F-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad wrote: > > Brian, > > On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote: > > If we achieve stable locators, this problem largely goes away, > > but stable names in themselves are insufficient IMHO. > > The problem isn't the DNS, but the concept of 'stable locators'. Given > the need to aggregate, you simply can't have stability in locators if > network topology changes. Yes and no. That's to say that on certain assumptions (i.e. the assumptions built into map+encap, 8+8, GSE, and MHAP) you can have a much more stable locator than today. Such locators are stable under a variety of *localized* topology changes, but not all of course. I should have made it clear that is what I meant. (I think the Tony Hain flavour of PI would also have a similar degree of stability.) > Since locators need to change when topology > changes, any solution you come up with will need to deal with > propagation delay and security while at the same time dealing with > scalability and performance. I would argue that the DNS can be > contorted to deal with these requirements (although whether or not > you'd want to is another question). Indeed. My view is that chances of suitably contorting DNS are much greater with the relatively stable locators I am thinking of. 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 Mon Feb 3 08:58:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13GwuQb007271; Mon, 3 Feb 2003 08:58:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13GwuX4007270; Mon, 3 Feb 2003 08:58:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13GwpQb007260 for ; Mon, 3 Feb 2003 08:58:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13Gx0VL027580 for ; Mon, 3 Feb 2003 08:59:00 -0800 (PST) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07381 for ; Mon, 3 Feb 2003 09:58:55 -0700 (MST) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9Q006NWSI6OO@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 03 Feb 2003 09:58:55 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9Q00BQYSI4D8@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 03 Feb 2003 09:58:54 -0700 (MST) Date: Mon, 03 Feb 2003 08:59:57 -0800 From: Alain Durand Subject: Re: Node Requirements and 3041 In-reply-to: To: john.loughney@nokia.com Cc: Samita.Chakrabarti@eng.sun.com, ipng@sunroof.eng.sun.com, brian@hursley.ibm.com, Francis.Dupont@enst-bretagne.fr Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, February 3, 2003, at 05:28 AM, john.loughney@nokia.com wrote: > > It should be something like that, but I think Alain was suggesting that > a node-based policy would not be sufficient. It should be at least > application based policy, since different applications will not > work with 3041 addresses. > > br, > John And even 'application based' is not enough. Think about an application like netscape. As a web browser, in its dialog to web servers, it may want to benefit from 3041. As a Mail user agent, when talking to its SMTP server, it may want not to use 3041 because the anti-spam rules might reject its mail (no reverse path DNS records), when talking to a FTP server,it may also be rejected for the same reason. So a socket option seems to me the right way to toggle 3041 on and off. - Alain. ps: btw, in case of application level failure as described above, should the app that was using 3041 retry with a regular 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 Mon Feb 3 09:10:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13HA0Qb007475; Mon, 3 Feb 2003 09:10:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13HA0d0007474; Mon, 3 Feb 2003 09:10:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13H9vQb007467 for ; Mon, 3 Feb 2003 09:09:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13HA6VL001386 for ; Mon, 3 Feb 2003 09:10:06 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17269 for ; Mon, 3 Feb 2003 10:10:00 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h13H9xJ2031374; Mon, 3 Feb 2003 12:09:59 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h13H9wSe138948; Mon, 3 Feb 2003 10:09:59 -0700 Importance: Normal Sensitivity: Subject: ipAddressTable in new, version-neutral RFC2011 draft To: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Mon, 3 Feb 2003 12:09:56 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/03/2003 10:09:58 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am posting this to both the IPv6 and MIB mailing lists to get the benefit of both groups' feedback. On our platform we support IP addresses that exist on multiple hosts but are only owned (i.e., advertised to routers) by one of these hosts. They exist on the other hosts as part of a workload balancing function for TCP connections. This has caused problems for some network management apps that provide topology discovery information using data obtained from the SNMP ipAddrTable from RFC2011. When the management app sees the same IP address in the ipAddrTable from 2 different hosts, the app thinks the IP address has moved. Is there a recommended way of reporting these addresses? Now we are looking into implementing the ipAddressTable from the replacement for RFC2011, draft-ietf-ipv6-rfc2011-update-01.txt. Would it be appropriate for us to use values of either the ipAddressOrigin or the ipAddressStatus MIB objects for these IP addresses, to indicate that they are not really owned by a host even though they appear in that host's ipAddressTable? If so, which values of which MIB object would be appropriate for us to use? And should we use a null RowPointer for the ipAddressPrefix MIB object for these IP addresses? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 Mon Feb 3 09:30:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13HUPQb007628; Mon, 3 Feb 2003 09:30:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13HUP1E007627; Mon, 3 Feb 2003 09:30:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13HULQb007620 for ; Mon, 3 Feb 2003 09:30:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13HUTVK023140 for ; Mon, 3 Feb 2003 09:30:30 -0800 (PST) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03404 for ; Mon, 3 Feb 2003 10:30:24 -0700 (MST) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9Q00LWTTYNN5@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 03 Feb 2003 10:30:24 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9Q00BIFTYMD8@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 03 Feb 2003 10:30:23 -0700 (MST) Date: Mon, 03 Feb 2003 09:31:27 -0800 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt In-reply-to: <3E3E8481.ECBFB4BA@hursley.ibm.com> To: Brian E Carpenter Cc: Bob Hinden , Pekka Savola , ipng@sunroof.eng.sun.com Message-id: <52FAD69F-379D-11D7-9063-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, February 3, 2003, at 07:02 AM, Brian E Carpenter wrote: >> >> Lets try to avoid a lengthily discussion on this. I think the w.g. >> has >> more pressing issues. If others have strong feeling on this, I am >> happy to >> change it. Or remove it. > > It's clear we won't converge rapidly on a specific choice, so I'd > suggest removing it so we can go quickly to a Last Call on this draft. > > Actually, we could simply ask IANA to reserve a /32 prefix for > documentation > purposes; it doesn't need an RFC. I understand that this issue is not as sexy as site local addresses, but there are people writing doc at this very moment. They need to know which prefix to use. They don't care much if it is 2000:0000::/32, 2000:0001::/32, 2000:0002::/32 or anything else, what they care is that something is decided. I sincerely hope the IETF is not going to wait it's apparently normal 2.5 year process to solve that simple issue. Please decide and decide quickly. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 3 09:35:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13HZAQb007717; Mon, 3 Feb 2003 09:35:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13HZ9di007716; Mon, 3 Feb 2003 09:35:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13HZ6Qb007709 for ; Mon, 3 Feb 2003 09:35:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13HZFVL010174 for ; Mon, 3 Feb 2003 09:35:15 -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 KAA11829 for ; Mon, 3 Feb 2003 10:35:08 -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 JAA18285 for ; Mon, 3 Feb 2003 09:35:08 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h13HZ7K11638; Mon, 3 Feb 2003 09:35:07 -0800 X-mProtect: <200302031735> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYeXGTp; Mon, 03 Feb 2003 09:35:05 PST Message-Id: <4.3.2.7.2.20030203092405.032fe968@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Feb 2003 09:34:37 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Documentation Prefix Cc: hinden@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 Patrick Grossetete just pointed out to me that there is already a prefix allocated (by APNIC) for documentation. It is: 2001:0DB8::/32 For more details see: http://www.apnic.org/info/faq/ipv6-documentation-prefix-faq.html#3 Since I don't think we need two, I will remove the one I proposed from and submit a new draft. 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 Mon Feb 3 10:54:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13IsEQb009228; Mon, 3 Feb 2003 10:54:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13IsEQO009227; Mon, 3 Feb 2003 10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13IsBQb009220 for ; Mon, 3 Feb 2003 10:54:11 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13IsKVL007132 for ; Mon, 3 Feb 2003 10:54:20 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12127 for ; Mon, 3 Feb 2003 10:54:13 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13F0UH3024074; Mon, 3 Feb 2003 16:00:41 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13F06J3074360; Mon, 3 Feb 2003 16:00:06 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33046 from ; Mon, 3 Feb 2003 16:00:02 +0100 Message-Id: <3E3E83C4.E62AED86@hursley.ibm.com> Date: Mon, 03 Feb 2003 15:59:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Fri, 31 Jan 2003, Michel Py wrote: > > > The specific format of global unicast address under the 2000::/3 > > > prefix is: > > > | 3 | n bits | 61-n bits | 64 bits | > > > +---+--------------------+-----------+----------------------------+ > > > |001| routing prefix | subnet ID | interface ID | > > > +---+--------------------+-----------+----------------------------+ > > > > I have a dumb question about this: I read a while ago in some RIR > > documents about the "hard boundary" at /64 and the "soft boundary" at > > /48. Technically, the subnet ID can have any number of bits, but I > > thought we would want to encourage the use of 16 subnet ID bits, which > > would make n=45. > > > > I think there could be something such as a recommendation or a should in > > the draft. > > I disagree about recommendations on this to-be-normative RFC. An > informative reference for recomendations in the IESG/IAB document is most > that could be acceptable. Pekka is correct. The /48 boundary is not the IETF's business any more; we had a very complex discussion with the RIRs and they had a very complex discussion among themselves, resulting in RIPE-267 and RIPE-261. Don't go there. (see http://www.ripe.net/ripe/docs/ipv6.html) 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 Mon Feb 3 13:23:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13LNYQb011052; Mon, 3 Feb 2003 13:23:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13LNX5O011051; Mon, 3 Feb 2003 13:23:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13LNUQb011044 for ; Mon, 3 Feb 2003 13:23:30 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13LNdVL024680 for ; Mon, 3 Feb 2003 13:23:39 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03197 for ; Mon, 3 Feb 2003 13:23:33 -0800 (PST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 03 Feb 2003 13:23:32 -0800 Reply-To: From: "Tony Hain" To: "'Dan Lanciani'" , Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 3 Feb 2003 13:23:29 -0800 Message-ID: <02f201c2cbca$7f470bb0$b99b46ab@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200302010055.TAA25088@ss10.danlan.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h13LNUQb011045 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > "Tony Hain" wrote: > > |Suspend disbelief for a moment, and consider a name > resolution service > |where the consumer edge widget was responsible for both tracking > |topology changes, and updating a branch of the name tree to keep it > |aligned. Said widget would need a secure mechanism to graft > itself to > |the name tree after an address change, but otherwise might > look like a > |typical DNS server. [...] > > It's not much of a suspension. I've been saying for years > that exactly such a mechanism is necessary to push the > routing task out to the end nodes where ample resources will > be available. If it isn't done at some other level it will > have to happen in the DNS. However, I believe that the DNS > is the wrong place for it. There is an important difference between pushing all the way to the end system, vs. the edge router. While architecturally there is little difference, when the mapping function is in the end system the level of churn on the registration infrastructure is substantially higher. Moving that to the consumer edge/set top provides both a platform that is generally more stable in its availablity, as well as an aggregation point for the bulk of the device churn. > > |Given that as a > |starting point, there is no obvious reason that using name > strings as > |the identifier is more difficult than any other approach. > > Using name strings may be no more difficult with respect to > the implementation of the name service, but it leverages far > less existing code than would a fixed- length binary > identifier. Existing code is not a reasonable argument to justify the architectural change of inserting an additional name service into the system. > Consider the advantages of using an identifier > that has exactly the same format as what we currently call an > address, i.e., 128 bits. With translation happening near the > bottom of the IP layer, no changes would be necessary in tcp > or in applications. Unless the application was trying to associate the source address of the packet with something it knows about. If there is a 'transparent' mapping function in the system, apps that expect that service will break. If such a mapping service is to work with said apps, there needs to be a mechanism to distribute the mapping table with some level of authenticity. If you are talking about essentially in-line encaps like 8+8, every routing edge would need to map the source locator as well as destination. > The problem of tcp connections > (not) surviving renumbering would disappear. The DNS would > work just the way it is, so no duplicate effort would be > required. Wait, a string to string translation happens in the DNS, then you claim another string to string translation is not a duplicate effort !?!?! > With a little care, multi- homing could be > supported. I suspect that mobile IP would be a lot easier as > well. In contrast, if we fix the DNS to track the topology, > names would have to replace addresses in tcp control blocks > (and packets and many other places) before we would start to > see the aforementioned benefits. > > I have proposed a simple, scalable mapping service that is > vaguely like the DNS in structure but whose purpose is to map > 128-bit identifiers into 128-bit locators (where these > locators correspond to what we currently use as addresses and > treat more as routes) in a flexible way. A request to the > root of this mapping service would be of the form, ``tell me > about this 128-bit identifier.'' A response would either be a > referal to other servers along with a mask to indicate what > other requests should go to that same set of servers or an > answer in the form of a mapping from identifier (with > possible wildcard bits indicated by a mask) to locator (also > with possible wildcards to be filled in from the identifier). The request/response is not the problem. Explain how it handles a scalable, secure update as nodes move between 802.11 hotspots of different providers. If that problem is solved, there is no reason for such a mapping system be limited to 16B fixed length strings. > The latter final response is assumed to come from a server > under the control of the owner of the identifier. Basically what I was suggesting by pushing the service to the customer edge. > Obviously, > responses would also include the usual TTL values and such > much as a DNS response does. The mapping service actually > scales a lot better than the DNS because it can increase the > depth of the tree as necessary by splitting on arbitrary bit > fields in the identifier. This should be transparent (think > unix DBM). The only thing that limits DNS is the assumption that the branching is limited. If name strings were device.customer.aol.cc... there is no real difference to parsing on a bit boundary. Tony > > 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 Mon Feb 3 13:55:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13LtWQb011450; Mon, 3 Feb 2003 13:55:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13LtWxL011449; Mon, 3 Feb 2003 13:55:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13LtTQb011442 for ; Mon, 3 Feb 2003 13:55:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13LtcVK028117 for ; Mon, 3 Feb 2003 13:55:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01969 for ; Mon, 3 Feb 2003 13:55:32 -0800 (PST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 03 Feb 2003 13:55:31 -0800 Reply-To: From: "Tony Hain" To: "'David Conrad'" , "'Dan Lanciani'" Cc: Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 3 Feb 2003 13:55:27 -0800 Message-ID: <02f601c2cbce$f654f6a0$b99b46ab@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h13LtTQb011443 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad wrote: > ... > Assume at the end point an address consists of a 64 bit value stuffed > into the lower 8 bytes of an IPv6 address with the upper 64 bits 0. > > The lower 64 bits of the destination would be put into an > in-addr.arpa-like tree, mapping that end point into multiple AAAAs > (which have their lower 64 bits set to 0) that correspond to the edge > routers associated with the multiple paths to the destination. The problem that needs to be solved is how this is done in a secure, scalable way as said node moves between something like 802.11 hotspots. > > Packet hits the source edge router for the first time, a DNS lookup > occurs fetching the multiple locators and caching them. The edge > router then bitwise ORs one of the locators (how the locator > is chosen > is left to the reader as an exercise) with the end point address, > forming a full 128 bit address. Obviously, you'd want to have the > source edge router keep the cache entry up to date as long as packets > are flowing to the destination (e.g., re-fetch at TTL/2 or whatever). I don't follow these steps. How does the origin get from AAAA records with only locators for the provider edge router, to a 128 bit entry? The only way I can figure this out is for 1) src looks up AAAA for name string, receives low 64 bits; 2) looks up in-addr of low 64 bits, receives name strings for current service provider edge routers; 3) looks up name strings of current service provider edge routers, receives set of upper 64 bit values that could be appended. All those steps only minimize churn on the forward tree. There is still a need to churn the reverse tree as the node moves. > > On the receiving end, the destination edge router receives > the packet, > zeros out the top 64 bits of the destination address (thereby > avoiding > NAT nightmares) and forwards the packet on to the destination. This would not really be necessary as the dst could just as easily ignore the upper 64 bits. The real question is where such a system ends up pushing the complexity to. Take the example of simple spam filtering in a mail server (since I happened to be working on that this morning). A simple filter might look like 66.154.0.0/18 because I know I have no valid reason to receive mail from CONEPUPPY-COM or its customers. If we change the system to remove any indication of routing infrastructure from the bits an application sees, there will be an increase in traffic that is trying to figure out where a random 64 bit identifier string came from. > > Renumbering thereby becomes merely an exercise in modifying the end > point 64 bit in-addr.arpa-like entry and waiting for the > cache entry to > time out. For mobile devices those cache entries will need to be on the order of minutes, and there is a missing discussion of how the update is authenticated, and its impact on overall network traffic. > > End point identifiers would be non-topologically sensitive > and could be > permanently assigned with absolutely no hierarchy (if desired). > Locators would still be topologically sensitive, but end users would > never see them or know about them, thus topology changes can be done > transparently. We are squeezing a balloon here. The more we optimize the routing infrastructure, the more we will end up complicating another area (see above discussion about spam filters). > > Even more fun: assume that the first four bytes of the end point > address aren't used during a transition period and the last > four bytes > encodes (say) an IPv4 address.... > > > I suspect that mobile IP would be a lot easier as well. > > Mobility is a bit trickier due to the DNS security and > caching model. > However, I believe it may be possible with the use of SIG(0) > and having > destination edge routers act as forwarding agents for a TTL. > This bit > needs more thought... > > > In contrast, if we fix the DNS to track the topology, names > would have > > to replace addresses in tcp control blocks (and packets and > many other > > places) > > before we would start to see the aforementioned benefits. This depends on the frequency of topology change. If the topology change period is significantly longer than the duration of an application stream, no change is necessary. On the other hand, we know that mobile devices exist (specifically consider a suspended laptop) so from the application perspective topology changes happen much more frequently than they are ready to deal with. In terms of return on investment, I would argue that we should be insisting that apps start using name strings in control blocks, and that all the arcane cruft that we now call DNS get replaced by a distributed database with minimal replication, and strong authentication of dynamic bindings. Tony > > Ick. > > Rgds, > -drc > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mon Feb 3 14:16:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13MGPQb011621; Mon, 3 Feb 2003 14:16:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13MGPIi011620; Mon, 3 Feb 2003 14:16:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13MGLQb011613 for ; Mon, 3 Feb 2003 14:16:21 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h13MGREK644765; Mon, 3 Feb 2003 14:16:27 -0800 (PST) Message-Id: <200302032216.h13MGREK644765@jurassic.eng.sun.com> Date: Mon, 3 Feb 2003 14:16:35 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: Node Requirements and 3041 To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com, brian@hursley.ibm.com, Francis.Dupont@enst-bretagne.fr, alain.durand@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MZfFEnf6iXcJFDNhuVzs1w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, > > If so, would it be clearer to say something like the following ? > > > > 'It is recommended that the node be configurable to turn on/off > > the privacy extension for stateless address autoconfiguration, when > > it is implemented.' > > It should be something like that, but I think Alain was suggesting that > a node-based policy would not be sufficient. It should be at least > application based policy, since different applications will not > work with 3041 addresses. > I agree with Alain that node-based policy is not sufficient at all and per-socket policy is needed for an application to choose temporary or default public address as the source address. I originally thought that two types of configurations are needed in the system: 1) configure the ability to configure a privacy extension interface when the feature is implemented ( i.e. even when the code is there, system may choose not to turn on privacy extension autoconfiguration). 2) per-socket source address selection preference to choose the privacy address when the address is configured in the system. Also, it would be good idea to have a brief discussion on the consequences of using privacy extension or a pointer to the relevant section of RFC3041 where it disucusses that would be useful for implementors to make a choice. Thanks, -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 3 14:57:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13MvjQb012187; Mon, 3 Feb 2003 14:57:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13Mvjth012186; Mon, 3 Feb 2003 14:57:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13MvgQb012179 for ; Mon, 3 Feb 2003 14:57:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13MvoVK019571 for ; Mon, 3 Feb 2003 14:57:50 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08228 for ; Mon, 3 Feb 2003 15:57:43 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA04211; Mon, 3 Feb 2003 17:57:38 -0500 (EST) Date: Mon, 3 Feb 2003 17:57:38 -0500 (EST) From: Dan Lanciani Message-Id: <200302032257.RAA04211@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" wrote: |Dan Lanciani wrote: |> "Tony Hain" wrote: |> |> |Suspend disbelief for a moment, and consider a name |> resolution service |> |where the consumer edge widget was responsible for both tracking |> |topology changes, and updating a branch of the name tree to keep it |> |aligned. Said widget would need a secure mechanism to graft |> itself to |> |the name tree after an address change, but otherwise might |> look like a |> |typical DNS server. [...] |> |> It's not much of a suspension. I've been saying for years |> that exactly such a mechanism is necessary to push the |> routing task out to the end nodes where ample resources will |> be available. If it isn't done at some other level it will |> have to happen in the DNS. However, I believe that the DNS |> is the wrong place for it. | |There is an important difference between pushing all the way to the end |system, vs. the edge router. While architecturally there is little |difference, when the mapping function is in the end system the level of |churn on the registration infrastructure is substantially higher. Why? The level of churn is determined by how often you renumber, not by where you translate the identifier to the locator. |Moving |that to the consumer edge/set top provides both a platform that is |generally more stable in its availablity, as well as an aggregation |point for the bulk of the device churn. My proposal works equally well in end nodes or in edge routers. Obviously you get somewhat more benefit from a shared cache on the edge router, but you seem to be saying something more significant is going on. |> |Given that as a |> |starting point, there is no obvious reason that using name |> strings as |> |the identifier is more difficult than any other approach. |> |> Using name strings may be no more difficult with respect to |> the implementation of the name service, but it leverages far |> less existing code than would a fixed- length binary |> identifier. | |Existing code is not a reasonable argument to justify the architectural |change of inserting an additional name service into the system. Is existing code a reasonable argument for sticking with the current system? Inertia seems to be the justification for much of what we have. Any new system that required wholesale changes in higher layers would be shot down for just that reason. You can't have it both ways. |> Consider the advantages of using an identifier |> that has exactly the same format as what we currently call an |> address, i.e., 128 bits. With translation happening near the |> bottom of the IP layer, no changes would be necessary in tcp |> or in applications. | |Unless the application was trying to associate the source address of the |packet with something it knows about. This doesn't make any sense. The applications never see anything but the portable identifiers. |If there is a 'transparent' |mapping function in the system, apps that expect that service will |break. Applications won't "expect" anything. If this system were implemented it would simply replace what we currently call addresses with portable identifiers. |If such a mapping service is to work with said apps, there needs |to be a mechanism to distribute the mapping table with some level of |authenticity. Not the table, just the entries that are of interest to particular consumers. Why do you believe that this is any more difficult than what DNS is currently expected to do? |If you are talking about essentially in-line encaps like |8+8, every routing edge would need to map the source locator as well as |destination. Yes, of course the source has to be mapped as well. There are different ways to handle this, perhaps avoiding the overhead of explicitly carrying around both values. See my original notes in the Sep. 99 archives for some possibilities. |> The problem of tcp connections |> (not) surviving renumbering would disappear. The DNS would |> work just the way it is, so no duplicate effort would be |> required. | |Wait, a string to string translation happens in the DNS, then you claim |another string to string translation is not a duplicate effort !?!?! No, you are completely missing the point. If the fast-changing mappings are handled in a separate 128b->128b transformation (one perhaps optimized just for this purpose) then there is no need to fix the existing DNS to deal with fast-changing mappings. The DNS would continue to hold long-term mappings (from name to portable identifier) which could continue to be updated with the existing semi-manual process. The duplicate effort that is avoided is that of enhancing the DNS to deal with fast-changing dymanic mappings. |The request/response is not the problem. Explain how it handles a |scalable, secure update as nodes move between 802.11 hotspots of |different providers. You are introducing a different problem. I proposed only to fix the aggregation/allocation/renumbering mess. I said it would likely make mobile IP easier; I didn't say it would make it free. How exactly do you think the use of arbitrary strings will solve the new problem that you have introduced? |If that problem is solved, there is no reason for |such a mapping system be limited to 16B fixed length strings. There is no correlation between solving that problem and selecting a 128->128 mapping. The latter is purely a matter of convenience for existing code. If you want to scrap the entire existing v6 suite and start over then I'd be happy to help, but I don't think that is going to happen. If we did do this then we could just start with an explicit source-route model and avoid the trap from the beginning. |> The latter final response is assumed to come from a server |> under the control of the owner of the identifier. | |Basically what I was suggesting by pushing the service to the customer |edge. We seem to be confusing two different things. The actual transformation of addresses in packets can happen at end nodes or in edge routers. The servers that provide the information necessary to perform those mappings can exist anywhere, much as DNS servers do today. I would not be inclined to make the latter servers resident within the edge routers, but it is not out of the question. |> Obviously, |> responses would also include the usual TTL values and such |> much as a DNS response does. The mapping service actually |> scales a lot better than the DNS because it can increase the |> depth of the tree as necessary by splitting on arbitrary bit |> fields in the identifier. This should be transparent (think |> unix DBM). | |The only thing that limits DNS is the assumption that the branching is |limited. If name strings were device.customer.aol.cc... there is no real |difference to parsing on a bit boundary. Are you kidding? Yes, sure, if you made domain allocation hierarchical and forced people to change their names when they changed providers then there would be more opportunity for deepening the tree. This would make names almost as useless as addresses. Talk about a step in the wrong direction... 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 Mon Feb 3 16:03:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1403dQb012644; Mon, 3 Feb 2003 16:03:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1403dTX012643; Mon, 3 Feb 2003 16:03:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1403aQb012636 for ; Mon, 3 Feb 2003 16:03:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1403iVK011160 for ; Mon, 3 Feb 2003 16:03:45 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12878 for ; Mon, 3 Feb 2003 17:03:37 -0700 (MST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 03 Feb 2003 16:03:08 -0800 Reply-To: From: "Tony Hain" To: "'Dan Lanciani'" , Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 3 Feb 2003 16:02:58 -0800 Message-ID: <02fd01c2cbe0$c6ac2b00$b99b46ab@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200302032257.RAA04211@ss10.danlan.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1403aQb012637 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > | ... > |There is an important difference between pushing all the way > to the end > |system, vs. the edge router. While architecturally there is little > |difference, when the mapping function is in the end system > the level of > |churn on the registration infrastructure is substantially higher. > > Why? The level of churn is determined by how often you > renumber, not by where you translate the identifier to the locator. Ok, that was not well worded. Any node that renumers will have to update some mapping server in the network. That function will require some authenticity, therefore a scalable trust model. If we put the identified/locator mapping function on the consumer side of the existing routing trust boundary, the authentication tools we have today will scale (ie: ISP cert in edge router, shared secret for consumer devices). If my devices show up at different networks and registers their new addresses with my edge router at home, the scaling impact is substantially lower than if they all try to update some central store in the ISP. > > |Moving > |that to the consumer edge/set top provides both a platform that is > |generally more stable in its availablity, as well as an aggregation > |point for the bulk of the device churn. > > My proposal works equally well in end nodes or in edge > routers. Obviously you get somewhat more benefit from a > shared cache on the edge router, but you seem to be saying > something more significant is going on. I am sure we can make mechanisms work either way, but there is a trust boundary here and the more often we cross it the more complex the tools become. > > Is existing code a reasonable argument for sticking with the > current system? Inertia seems to be the justification for > much of what we have. Any new system that required wholesale > changes in higher layers would be shot down for just that > reason. You can't have it both ways. I am not arguing that we can't change the higher layers. All I was pointing out was that using something that exists to justify defining something completely new is broken. If we are really talking about a completely new architecture we should not assume that any existing code will meet the yet to be defined requirements. It might work out that way, but we can't base the decision on it. > ... > |Unless the application was trying to associate the source address of > |the packet with something it knows about. > > This doesn't make any sense. The applications never see > anything but the portable identifiers. Consider the SMTP server that wants to reject connections from a group of servers. If there is no indication of topological grouping, that server would have to look up all the portable identifiers to find out what to filter. > > |If there is a 'transparent' > |mapping function in the system, apps that expect that service will > |break. > > Applications won't "expect" anything. If this system were > implemented it would simply replace what we currently call > addresses with portable identifiers. No, it is very different. Current portable identifiers include some degree of topology information. > > |If such a mapping service is to work with said apps, there > needs to be > |a mechanism to distribute the mapping table with some level of > |authenticity. > > Not the table, just the entries that are of interest to > particular consumers. Why do you believe that this is any > more difficult than what DNS is currently expected to do? Scale. If every device on the net today were registered in DNS & could change that registration at will for topology changes, they I would agree. Reality is that the current DNS handles a very small subset of nodes, and the vast majority of those are static entries. The reasons for this are lack of a trust infrastructure to allow arbitrary updates, coupled with the lack of distribution appropriate to accommodate the scale. We can't give DNS servers to the consumer because the existing system is too arcane, and we can't support DDNS for every network enabled device in the ISP servers because we don't have a trust model that scales. > > |If you are talking about essentially in-line encaps like > |8+8, every routing edge would need to map the source locator > as well as > |destination. > > Yes, of course the source has to be mapped as well. There > are different ways to handle this, perhaps avoiding the > overhead of explicitly carrying around both values. See my > original notes in the Sep. 99 archives for some possibilities. Optimizing in one place just moves the problem somewhere else. > > |> The problem of tcp connections > |> (not) surviving renumbering would disappear. The DNS would > |> work just the way it is, so no duplicate effort would be > |> required. > | > |Wait, a string to string translation happens in the DNS, > then you claim > |another string to string translation is not a duplicate effort !?!?! > > No, you are completely missing the point. If the > fast-changing mappings are handled in a separate 128b->128b > transformation (one perhaps optimized just for this purpose) > then there is no need to fix the existing DNS to deal with > fast-changing mappings. The DNS would continue to hold > long-term mappings (from name to portable identifier) which > could continue to be updated with the existing semi-manual > process. The duplicate effort that is avoided is that of > enhancing the DNS to deal with fast-changing dymanic mappings. At the expense of having to do two mappings for every connection. The proposal is to make the whole system slower rather than fix the problem at the source. > > |The request/response is not the problem. Explain how it handles a > |scalable, secure update as nodes move between 802.11 hotspots of > |different providers. > > You are introducing a different problem. No, that is the core of the DNS problem. DNS can already handle the request/response load. What it doesn't do is provide a scalable way to update the changes. > I proposed only to > fix the aggregation/allocation/renumbering mess. I said it > would likely make mobile IP easier; I didn't say it would > make it free. How exactly do you think the use of arbitrary > strings will solve the new problem that you have introduced? It is not a new problem, and I am just pointing out that inserting a new name system doesn't do any good unless it solves the authentication issues. If it does that, there is no reason to limit it to fixed length strings. > > |If that problem is solved, there is no reason for > |such a mapping system be limited to 16B fixed length strings. > > There is no correlation between solving that problem and > selecting a 128->128 mapping. The latter is purely a matter > of convenience for existing code. If you want to scrap the > entire existing v6 suite and start over then I'd be happy to > help, but I don't think that is going to happen. If we did > do this then we could just start with an explicit > source-route model and avoid the trap from the beginning. If one only looks at the resolution part of the problem, then existing code and fixed lengths are a natural draw. The reason this exercise is even being undertaken is that we don't have the authentication infrastructure to update mappings to begin with. If we create that infrastructure it would apply just as well to DNS, so why would we need multiple layers of name to address translation. > > |> The latter final response is assumed to come from a server > |> under the control of the owner of the identifier. > | > |Basically what I was suggesting by pushing the service to > the customer > |edge. > > We seem to be confusing two different things. The actual > transformation of addresses in packets can happen at end > nodes or in edge routers. The servers that provide the > information necessary to perform those mappings can exist > anywhere, much as DNS servers do today. I would not be > inclined to make the latter servers resident within the edge > routers, but it is not out of the question. It is a convinent aggregation point that aligns with the routing trust boundary. > > |> Obviously, > |> responses would also include the usual TTL values and such > |> much as a DNS response does. The mapping service actually > |> scales a lot better than the DNS because it can increase the > |> depth of the tree as necessary by splitting on arbitrary bit > |> fields in the identifier. This should be transparent (think > |> unix DBM). > | > |The only thing that limits DNS is the assumption that the > branching is > |limited. If name strings were device.customer.aol.cc... there is no > |real difference to parsing on a bit boundary. > > Are you kidding? Yes, sure, if you made domain allocation > hierarchical and forced people to change their names when > they changed providers then there would be more opportunity > for deepening the tree. This would make names almost as > useless as addresses. Talk about a step in the wrong direction... We are only moving the problems around here. People already deal with updating email addresses when they change providers, or employers, so it is within some degree of reason. For those that multi-home or want to mask their provider from the name, they can always register for a name in cc, then work out the authentication process with the providers. Tony > > 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 Mon Feb 3 19:14:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h143EEQb013190; Mon, 3 Feb 2003 19:14:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h143EEdT013189; Mon, 3 Feb 2003 19:14:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h143EAQb013182 for ; Mon, 3 Feb 2003 19:14:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h143EJVK004479 for ; Mon, 3 Feb 2003 19:14:19 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29186; Mon, 3 Feb 2003 20:14:14 -0700 (MST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h143E4Un058150; Mon, 3 Feb 2003 22:14:04 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-198-82.mts.ibm.com [9.65.198.82]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h143E2YD094974; Mon, 3 Feb 2003 20:14:03 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h143Bu204820; Mon, 3 Feb 2003 22:11:57 -0500 Message-Id: <200302040311.h143Bu204820@cichlid.adsl.duke.edu> To: Alain Durand cc: john.loughney@nokia.com, brian@hursley.ibm.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements and 3041 In-Reply-To: Message from Alain.Durand@Sun.COM of "Wed, 29 Jan 2003 09:25:30 PST." Date: Mon, 03 Feb 2003 22:11:56 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, All your points are valid, but I'd argue the node requirements document is the wrong place to have this level of detail. Instead, 3041 should be respun with more text about these issues. I think Node requirements would be better off (in general) just pointing to other basic documents and let folks go there for the details. If the details aren't there, the question should be asked whether a revision is approriate. 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 Mon Feb 3 19:31:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h143V6Qb013336; Mon, 3 Feb 2003 19:31:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h143V52D013335; Mon, 3 Feb 2003 19:31:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h143V2Qb013328 for ; Mon, 3 Feb 2003 19:31:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h143VBVL008174 for ; Mon, 3 Feb 2003 19:31:11 -0800 (PST) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05204 for ; Mon, 3 Feb 2003 20:31:05 -0700 (MST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id TAA22314; Mon, 3 Feb 2003 19:30:59 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 3 Feb 2003 19:30:58 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Juergen Schoenwaelder cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2) In-Reply-To: <200302031251.h13CpSDv029797@hansa.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Feb 2003, Juergen Schoenwaelder wrote: > Since forwarding architectures tend to look pretty different, I guess > we can't do more than using some opaque identifier - whether that is > an OBJECT IDENTIFIER, an INTEGER will some smart numbering scheme > (similar to SnmpSecurityModel), or an OCTET STRING does not really > make a big difference to me. In principle any one of those could be made to work, yes. > The problem is that mgmt applications either understand the > semantics of a particular implementation or they will have to > guess or ignore some rows. I undestand that a management application may not have full understanding of route table entries without understanding the nature of the opaque identifier. But I don't follow why that implies that a management application has to ignore some rows -- at least if all it's doing is inspecting rather than modifying the rows. The proposed index components are destination prefix, opaque identifier, and next hop. I can still determine how many routes to a given destination via a particular next hop exist (and query their other properties) even if I don't know what the opaque identifier is. [Note that the order given for the indices may not be the optimal one -- probably the opaque identifier should be last -- but that does not affect the information content.] > So from an interoperability point of view, all this is only > little better than not having such an index component. I don't think I agree. It's much better, because I can at least represent a forwarding architecture that permits multiple routes to a destination via the same next hop. Without the opaque identifier I could not do that. More generally, without the opaque identifier I could not map the table to an arbitrary forwarding architecture. It is true that it's best to split as much common stuff out of the opaque identifier as possible. If you can identify some additional generic candidate index components beside destination prefix and next hop please say so. //cmh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 3 20:58:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h144wLQb013759; Mon, 3 Feb 2003 20:58:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h144wL1W013758; Mon, 3 Feb 2003 20:58:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h144wIQb013751 for ; Mon, 3 Feb 2003 20:58:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h144wRVK020514 for ; Mon, 3 Feb 2003 20:58:27 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17743 for ; Mon, 3 Feb 2003 21:58:21 -0700 (MST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h144vE205264 for ; Tue, 4 Feb 2003 06:57:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 06:58:19 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 06:58:19 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 06:58:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node Requirements and 3041 Date: Tue, 4 Feb 2003 06:58:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements and 3041 Thread-Index: AcLL+3zsNWtzBSvJQO6qi9KEQQKxvAADnQiw To: , Cc: , , X-OriginalArrivalTime: 04 Feb 2003 04:58:19.0091 (UTC) FILETIME=[08E74A30:01C2CC0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h144wIQb013752 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I will re-read 3041, craft some text, point to a relevant section in 3041. I'll try to get this done today. thanks, John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 04 February, 2003 05:12 > To: Alain Durand > Cc: Loughney John (NRC/Helsinki); brian@hursley.ibm.com; > Francis.Dupont@enst-bretagne.fr; ipng@sunroof.eng.sun.com > Subject: Re: Node Requirements and 3041 > > > Alain, > > All your points are valid, but I'd argue the node requirements > document is the wrong place to have this level of detail. > > Instead, 3041 should be respun with more text about these issues. I > think Node requirements would be better off (in general) just pointing > to other basic documents and let folks go there for the details. If > the details aren't there, the question should be asked whether a > revision is approriate. > > 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 4 00:42:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h148gBQb014962; Tue, 4 Feb 2003 00:42:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h148gAj1014961; Tue, 4 Feb 2003 00:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h148g6Qb014954 for ; Tue, 4 Feb 2003 00:42:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h148gFVK028308 for ; Tue, 4 Feb 2003 00:42:15 -0800 (PST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12534 for ; Tue, 4 Feb 2003 01:42:07 -0700 (MST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h148fMvA022793 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 4 Feb 2003 09:41:22 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h148fMAa023522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 4 Feb 2003 09:41:22 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h148fLns023519; Tue, 4 Feb 2003 09:41:21 +0100 Date: Tue, 4 Feb 2003 09:41:21 +0100 Message-Id: <200302040841.h148fLns023519@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: heard@pobox.com CC: ipng@sunroof.eng.sun.com In-reply-to: (heard@pobox.com) Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2) References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> C M Heard writes: >> The problem is that mgmt applications either understand the >> semantics of a particular implementation or they will have to guess >> or ignore some rows. Mike> I undestand that a management application may not have full Mike> understanding of route table entries without understanding the Mike> nature of the opaque identifier. But I don't follow why that Mike> implies that a management application has to ignore some rows -- Mike> at least if all it's doing is inspecting rather than modifying Mike> the rows. The proposed index components are destination prefix, Mike> opaque identifier, and next hop. I can still determine how many Mike> routes to a given destination via a particular next hop exist Mike> (and query their other properties) even if I don't know what the Mike> opaque identifier is. Well, it depends what you expect from a management application. If your manager is a MIB brower which just shows the data to a human, things are fine. If however the management application want to reason about the data (e.g. which route will a packet with destination A take), then a totally opaque value basically means that the application can not answer this question. /js -- Juergen Schoenwaelder -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 02:57:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14AvdQb016049; Tue, 4 Feb 2003 02:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14AvcTD016048; Tue, 4 Feb 2003 02:57:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14AvZQb016041 for ; Tue, 4 Feb 2003 02:57:35 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14AviVL015959 for ; Tue, 4 Feb 2003 02:57:44 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18767 for ; Tue, 4 Feb 2003 02:57:38 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h14Auw2p061850; Tue, 4 Feb 2003 11:57:19 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h14AueHF106260; Tue, 4 Feb 2003 11:56:40 +0100 Received: from dhcp222-14.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31334 from ; Tue, 4 Feb 2003 11:56:39 +0100 Message-Id: <3E3F9C39.65882523@hursley.ibm.com> Date: Tue, 04 Feb 2003 11:55:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements and 3041 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, By "toggle 3041 on and off", do you mean toggling address selection to use an existing 3041 address, or generating a new 3041 address for each new connection that wants it? Brian Alain Durand wrote: > > On Monday, February 3, 2003, at 05:28 AM, john.loughney@nokia.com wrote: > > > > It should be something like that, but I think Alain was suggesting that > > a node-based policy would not be sufficient. It should be at least > > application based policy, since different applications will not > > work with 3041 addresses. > > > > br, > > John > > And even 'application based' is not enough. Think about an application > like netscape. As a web browser, in its dialog to web servers, it may > want > to benefit from 3041. As a Mail user agent, when talking to its SMTP > server, > it may want not to use 3041 because the anti-spam rules might reject its > mail (no reverse path DNS records), when talking to a FTP server,it may > also be rejected for the same reason. > > So a socket option seems to me the right way to toggle 3041 on and off. > > - Alain. > > ps: btw, in case of application level failure as described above, > should the app that was using 3041 retry with a regular 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 4 03:26:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14BQkQb016141; Tue, 4 Feb 2003 03:26:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14BQkL0016140; Tue, 4 Feb 2003 03:26:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14BQgQb016133 for ; Tue, 4 Feb 2003 03:26:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14BQoVK022577 for ; Tue, 4 Feb 2003 03:26:50 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (pop-ls-09-1-dialup-131.freesurf.ch [194.230.235.131]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11538 for ; Tue, 4 Feb 2003 04:26:42 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14BRghE023102; Tue, 4 Feb 2003 12:27:44 +0100 (CET) Date: Tue, 4 Feb 2003 11:03:31 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3E3A8F9E.9EC585D8@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Assuming? Hello? This exactly what PI is. If there is no central >>> routing >>> it's not PI anymore. PI is what we have _today_. >> >> Exactly. And today we don't have a billion routes. > > Fortunately enough, if you would like the routing algorithms to > converge in real time. > I rather come up with a solution to todays problems so we get time to work on tomorrows. If we aim for a 100% solution now, we will never get there. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 08:09:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14G9fQb017019; Tue, 4 Feb 2003 08:09:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14G9fb8017018; Tue, 4 Feb 2003 08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14G9cQb017011 for ; Tue, 4 Feb 2003 08:09:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14G9kVL009512 for ; Tue, 4 Feb 2003 08:09:46 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17097 for ; Tue, 4 Feb 2003 09:09:40 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h14G9dVE089486 for ; Tue, 4 Feb 2003 11:09:39 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h14G9bsJ082250 for ; Tue, 4 Feb 2003 09:09:38 -0700 Importance: Normal Sensitivity: Subject: new RFC2096 draft - should inetCidrRouteNextHopType still be defined? To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Tue, 4 Feb 2003 11:09:36 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/04/2003 09:09:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the November version of the new RFC2096 draft, the Revision History for 13 Jul 2002 states that the inetcidrRouteNextHopType MIB object was removed. But the definition of this MIB object still appears in the November version with a STATUS of "current". Is this MIB object still supported to be defined in the draft? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 4 08:29:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14GTrQb017190; Tue, 4 Feb 2003 08:29:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14GTrDR017189; Tue, 4 Feb 2003 08:29:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14GTnQb017182 for ; Tue, 4 Feb 2003 08:29:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14GTuVL014808 for ; Tue, 4 Feb 2003 08:29:57 -0800 (PST) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16734 for ; Tue, 4 Feb 2003 09:29:51 -0700 (MST) Received: from xpa-fe1 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9S004P3LTRT3@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 04 Feb 2003 09:29:51 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9S002FZLTPGB@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 04 Feb 2003 09:29:51 -0700 (MST) Date: Tue, 04 Feb 2003 08:30:56 -0800 From: Alain Durand Subject: Re: Node Requirements and 3041 In-reply-to: <3E3F9C39.65882523@hursley.ibm.com> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Message-id: <0931B5EB-385E-11D7-BE23-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk By "toggle 3041 on and off" I mean decide if 3041 is appropriate or not for that connection. Now, if the answer is yes, should a new address be generated or should you use an existing one, this is, IMHO, implementation dependent. I think it would make sense to generate a new one per connection for security concerns, but I understand that there may be some performance issue in doing so. - Alain. On Tuesday, February 4, 2003, at 02:55 AM, Brian E Carpenter wrote: > Alain, > > By "toggle 3041 on and off", do you mean toggling address selection to > use > an existing 3041 address, or generating a new 3041 address for each new > connection that wants it? > > Brian > > Alain Durand wrote: >> >> On Monday, February 3, 2003, at 05:28 AM, john.loughney@nokia.com >> wrote: >>> >>> It should be something like that, but I think Alain was suggesting >>> that >>> a node-based policy would not be sufficient. It should be at least >>> application based policy, since different applications will not >>> work with 3041 addresses. >>> >>> br, >>> John >> >> And even 'application based' is not enough. Think about an application >> like netscape. As a web browser, in its dialog to web servers, it may >> want >> to benefit from 3041. As a Mail user agent, when talking to its SMTP >> server, >> it may want not to use 3041 because the anti-spam rules might reject >> its >> mail (no reverse path DNS records), when talking to a FTP server,it >> may >> also be rejected for the same reason. >> >> So a socket option seems to me the right way to toggle 3041 on and >> off. >> >> - Alain. >> >> ps: btw, in case of application level failure as described above, >> should the app that was using 3041 retry with a regular 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 08:47:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14GlHQb017337; Tue, 4 Feb 2003 08:47:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14GlHpi017336; Tue, 4 Feb 2003 08:47:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14GlEQb017329 for ; Tue, 4 Feb 2003 08:47:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14GlLVL019636 for ; Tue, 4 Feb 2003 08:47:21 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (tele2-1-1-dialup-211.freesurf.ch [194.230.196.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10557; Tue, 4 Feb 2003 09:47:11 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14Gm9hE023284; Tue, 4 Feb 2003 17:48:10 +0100 (CET) Date: Tue, 4 Feb 2003 15:12:18 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Margaret Wasserman" , "Erik Nordmark" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B95@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> but even if we in San Fransisco would agree on a new routing model, >> it would still take us at least 3-5 years to implement. >> See the migration to BGP4 as example. > > 5 years is overly optimistic, IMHO. Probably. >> I say go for /48 PI space. Take a /16 (or something suitable) and >> divide it per RIR, and use it as PI space. > > This is way too risky. Potentially, 4 billion routes. I agree that we The 4 billion routes is a figure out of thin air. Let's solve todays problems first, and the we start worrying about the future. > don't have a problem in the short term. Until we get to 50k routes > nobody cares. I am more worried about ever reaching 1k, or 10k.... > But, doing this would put research efforts to a halt. 10 years down the On the contrary. It will buy us time and give us experience. I still argue that we are looking at solutions to a problem we still have not understood. I am not convinced that all DLS subscribers and PDAs won't PI space and multihoming. Multihoming comes at a cost. IPv6 in it self will come at a higher cost. Let's see who is willing to pay first. > road, suddenly we have 500k BGP 4+ and the Internet craps out. I don't > want to be the guy that recommended that we re-create the IPv4 swamp, > because this is exactly what we are talking about. Yupp. That is the advantage. We can take the same policy, and learn. No need for implementations or arguments over assignment policy. > 10 or 15 years ago, we gave away swamp space to anyone that wanted it > because nobody thought that it would ever have a scalability issue. 4 I wasn't around then, but from what I have been told and read I think everyone was very aware of the scaling issues. But decided to put them forward and buy time. > billion /48 prefixes in the global routing table, what do you call > this? > I call it IPv6 swamp. It is! No question, but do you want to wait 5+ years? - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 09:53:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14HrGQb017563; Tue, 4 Feb 2003 09:53:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14HrGb0017562; Tue, 4 Feb 2003 09:53:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14HrDQb017555 for ; Tue, 4 Feb 2003 09:53:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14HrLVK017768 for ; Tue, 4 Feb 2003 09:53:21 -0800 (PST) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26767 for ; Tue, 4 Feb 2003 10:53:15 -0700 (MST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id JAA10418; Tue, 4 Feb 2003 09:53:12 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 4 Feb 2003 09:53:11 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Kristine Adamson cc: ipng@sunroof.eng.sun.com Subject: Re: new RFC2096 draft - should inetCidrRouteNextHopType still be defined? 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 Tue, 4 Feb 2003, Kristine Adamson wrote: > In the November version of the new RFC2096 draft, the Revision History for > 13 Jul 2002 states that the inetcidrRouteNextHopType MIB object was > removed. But the definition of this MIB object still appears in the > November version with a STATUS of "current". Is this MIB object still > supported to be defined in the draft? I think the dates on the revision history blocks are a little messed up; they are certainly out-of-sequence. The Revision History for 27 Jun 2002 states that inetCidrRouteNextHopType was restored: Changes from draft-ietf-ipngwg-rfc-2096-update-00.txt: 27 Jun 2002 Added inetCidrRouteDscp index and inetCidrRouteWeight object to the inetCidrRouteTable. Restored inetCidrRouteNextHopType variable (may be different from inetCidrRouteDestType, due to global vs. non-global distinction in new InetAddress TCs). Removed inetCidrRouteInstance object. Use to identify a conceptual routing table is obviated by new InetAddress types and inclusion of DSCP index. Changed editor, moved author information to end, several editorial changes. Changed name to draft-ietf-ipv6-rfc-2096-update-*.txt 13 Jul 2002 Removed inetCidrRouteNextHopType. I also wondered of why inetCidrRouteNextHopType was needed when I was reading the MIB module last week, but I think the reason given in the 27 Jun 2002 revision block is correct, and that the object really does need to be there. //cmh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 4 12:28:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14KSJQb018147; Tue, 4 Feb 2003 12:28:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h14KSJvL018146; Tue, 4 Feb 2003 12:28:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h14KSFQb018139 for ; Tue, 4 Feb 2003 12:28:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h14KSNVL003620 for ; Tue, 4 Feb 2003 12:28:23 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22430 for ; Tue, 4 Feb 2003 13:28:17 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA07226; Tue, 4 Feb 2003 15:28:13 -0500 (EST) Date: Tue, 4 Feb 2003 15:28:13 -0500 (EST) From: Dan Lanciani Message-Id: <200302042028.PAA07226@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurt Erik Lindqvist wrote: |> But, doing this would put research efforts to a halt. 10 years down the | |On the contrary. It will buy us time and give us experience. And besides, a looming deadline might accelerate rather than halt research. Currently solutions to the renumbering/allocation/aggregation problem get very low priority exactly because of dependency on the PA hack. Hmm, for that matter, where is all this research that we are worrying about halting? |> 10 or 15 years ago, we gave away swamp space to anyone that wanted it |> because nobody thought that it would ever have a scalability issue. 4 | |I wasn't around then, but from what I have been told and read I think |everyone was very aware of the scaling issues. But decided to put them |forward and buy time. Well, I was around and I don't recall any major concern. We were aware that there might ultimately be a problem but we were much more open-minded about solutions relying both on faster hardware and on new protocols. I think that's why some (a lot?) of us were more than a little annoyed at being sandbagged by the "CIDR" two-step. What was supposed to be a temporary fix quickly evolved into the effective extinction of new portable addresses. Since then, hierarchical allocation has become so ingrained that some people have trouble even conceptualizing other solutions. 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 4 19:30:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h153ULQb020934; Tue, 4 Feb 2003 19:30:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h153ULhR020933; Tue, 4 Feb 2003 19:30:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h153UIQb020926 for ; Tue, 4 Feb 2003 19:30:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h153UQVL004966 for ; Tue, 4 Feb 2003 19:30:26 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26135 for ; Tue, 4 Feb 2003 20:30:18 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA06353; Tue, 4 Feb 2003 19:29:08 -0800 (PST) Message-Id: <5.1.0.14.2.20030204222244.034b2a48@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Feb 2003 22:24:47 -0500 To: Kristine Adamson From: Margaret Wasserman Subject: Re: new RFC2096 draft - should inetCidrRouteNextHopType still be defined? Cc: ipng@sunroof.eng.sun.com 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 Sorry, I mistyped on or the other of the two revision dates... The inetCidrRouteNextHopType is needed, because the two IP addresses may not be the same type. Although they both have to be the same IP version (v4 or v6), they may have different IPv6 scopes (i.e. one could be global and one non-global). So, we need two different types for the two different addresses. Margaret At 11:09 AM 2/4/2003 -0500, Kristine Adamson wrote: >In the November version of the new RFC2096 draft, the Revision History for >13 Jul 2002 states that the inetcidrRouteNextHopType MIB object was >removed. But the definition of this MIB object still appears in the >November version with a STATUS of "current". Is this MIB object still >supported to be defined in the draft? > >Thanks, > >Kristine Adamson >IBM Communications Server for MVS: TCP/IP Development >Internet e-mail:adamson@us.ibm.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 Tue Feb 4 20:38:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h154c2Qb021179; Tue, 4 Feb 2003 20:38:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h154c2C3021178; Tue, 4 Feb 2003 20:38:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h154bwQb021171 for ; Tue, 4 Feb 2003 20:37:59 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h154c7VK005025 for ; Tue, 4 Feb 2003 20:38: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 nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16607 for ; Tue, 4 Feb 2003 20:38:01 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Tue, 4 Feb 2003 20:38:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BB9@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcLMbQ5UV6n8Jcr5TN+XsLUtGF6OWgAVxWFQ From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h154bxQb021172 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurtis, >> Michel Py wrote: >> a billion /48 prefixes in the global routing table, what do >> you call this? I call it IPv6 swamp. > Kurt Erik Lindqvist wrote: > It is! No question, but do you want to wait 5+ years? You are missing the point. If we had a reasonable expectation that a scalable flat routing protocol would be available in 5 years, I would buy the argument. But what do we have today? Zero, not even a believable promise. This is why I used the term "gambling" before. What you are lobbying for is to say that it is OK to give away PI and create the IPv6 swamp because in 5 years we will be able to clean it because by then someone would have invented The Perfect Routing Protocol (C)(TM). We are not developing IPv6 to barely match what v4 does with a bigger address space. We need to make it better. In order to re-create the swamp you have to show a carrot the size of Texas and so far we've not even seen a peanut. 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 Tue Feb 4 20:41:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h154fwQb021198; Tue, 4 Feb 2003 20:41:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h154fw2U021197; Tue, 4 Feb 2003 20:41:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h154ftQb021190 for ; Tue, 4 Feb 2003 20:41:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h154g3VK005546 for ; Tue, 4 Feb 2003 20:42:03 -0800 (PST) Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06873 for ; Tue, 4 Feb 2003 21:41:58 -0700 (MST) Received: from Rich3800@aol.com by imo-r05.mx.aol.com (mail_out_v34.21.) id 1.1d5.1a8dfb7 (15887) for ; Tue, 4 Feb 2003 23:41:50 -0500 (EST) Received: from aol.com ([12.108.37.109]) by air-id08.mx.aol.com (v90_r2.5) with ESMTP id MAILINID82-0204234150; Tue, 04 Feb 2003 23:41:50 -0500 Message-ID: <3E4094CE.9010406@aol.com> Date: Tue, 04 Feb 2003 23:36:30 -0500 From: Rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Home network configuration Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We have a small network of 2 PCs, my Linux PC and her Win XP PC, all connected to the Internet through a SpeedStream DHCP NAT/router and a cable modem. I have another PC available to set up as a router/mrouter with whaterver OS would be most convenient to install. I know that it is very hard to reach a machine behind a NAT connection. For this reason, I want to replace my NAT router with something else so I can serve up files on my Linux machine as an IPv6/IPv4 web server. How would I go about it? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 5 00:26:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h158QwQb021941; Wed, 5 Feb 2003 00:26:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h158QwqR021940; Wed, 5 Feb 2003 00:26:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h158QsQb021933 for ; Wed, 5 Feb 2003 00:26:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h158R2VK017398 for ; Wed, 5 Feb 2003 00:27:02 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25990 for ; Wed, 5 Feb 2003 01:26:56 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h158Qrbt042686 for ; Wed, 5 Feb 2003 09:26:54 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h158QpWa103052 for ; Wed, 5 Feb 2003 09:26:52 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33838 from ; Wed, 5 Feb 2003 09:26:50 +0100 Message-Id: <3E40CA9B.141E9754@hursley.ibm.com> Date: Wed, 05 Feb 2003 09:26:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses References: <200302042028.PAA07226@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: ... > |I wasn't around then, but from what I have been told and read I think > |everyone was very aware of the scaling issues. But decided to put them > |forward and buy time. > > Well, I was around and I don't recall any major concern. This is hard to reconcile with some of the words in RFC 1380, or what I remember when I first arrived in late 1992. My recollection is of a consensus to buy time with CIDR. (Just as PA addressing in IPv6 buys time; this was in fact strongly debated during the formative stage of IPng in 1993/94.) > We were aware > that there might ultimately be a problem but we were much more open-minded > about solutions relying both on faster hardware and on new protocols. I > think that's why some (a lot?) of us were more than a little annoyed at > being sandbagged by the "CIDR" two-step. What was supposed to be a temporary > fix quickly evolved into the effective extinction of new portable addresses. > Since then, hierarchical allocation has become so ingrained that some people > have trouble even conceptualizing other solutions. It's true that RFC 1380 assumed hierarchical allocation. But it also clearly expressed the distinction between interim solutions (specifically CIDR) and the long term. What I think it missed was the whole topic of identifier/locator separation. That seems to be what we (for some definition of "we") need to focus on now. I don't think most people whose BGP tables were exploding felt in the least sandbagged by BGP4. 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 Wed Feb 5 02:41:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15Af5Qb022958; Wed, 5 Feb 2003 02:41:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15Af5lK022957; Wed, 5 Feb 2003 02:41:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15Af2Qb022948 for ; Wed, 5 Feb 2003 02:41:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15Af9VK008889 for ; Wed, 5 Feb 2003 02:41:09 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13575 for ; Wed, 5 Feb 2003 03:41:04 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Wed, 5 Feb 2003 00:31:06 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 4 Feb 2003 21:40:26 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Feb 2003 21:40:43 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.196]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 4 Feb 2003 21:40:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Home network configuration Date: Tue, 4 Feb 2003 21:40:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Home network configuration thread-index: AcLM0whSxpfT9iBcRPKwt1yL+SoyowAAj3eQ From: "Brian Zill" To: "Rich3800" , X-OriginalArrivalTime: 05 Feb 2003 05:40:43.0685 (UTC) FILETIME=[20034550:01C2CCD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h15Af2Qb022949 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, questions like this are probably best discussed on the IPv6 users list (users@ipv6.org). The ipng list is for IETF standards development. Probably the easiest thing to do in your situation (assuming you're not double NAT'd) would be to replace your existing NAT with a PC that could serve as a combination NAT (for v4 connectivity) and 6to4 router (for v6 connectivity). That would give all the hosts behind this box private IPv4 addresses and global IPv6 addresses. Alternatively, you could do the same except that instead of setting up the PC router as a 6to4 gateway for your site, set up a configured tunnel to a tunnel broker somewhere. This takes a little more effort but doesn't require sending your traffic through a 6to4 relay to reach non-6to4 sites on the 6bone. It's easy to set up a Windows XP box as a 6to4 router, but I believe most other popular OSes have such support now as well. --Brian > -----Original Message----- > From: Rich3800 [mailto:Rich3800@aol.com] > Sent: Tuesday, February 04, 2003 20:37 > To: ipng@sunroof.eng.sun.com > Subject: Home network configuration > > > Hi, > > We have a small network of 2 PCs, my Linux PC and her Win XP PC, all > connected to the Internet through a SpeedStream DHCP NAT/router and a > cable modem. I have another PC available to set up as a > router/mrouter > with whaterver OS would be most convenient to install. I > know that it > is very hard to reach a machine behind a NAT connection. For this > reason, I want to replace my NAT router with something else so I can > serve up files on my Linux machine as an IPv6/IPv4 web server. How > would I go about it? > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 5 02:56:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15AufQb023205; Wed, 5 Feb 2003 02:56:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15AueMB023204; Wed, 5 Feb 2003 02:56:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15AubQb023197 for ; Wed, 5 Feb 2003 02:56:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15AujVK011058 for ; Wed, 5 Feb 2003 02:56:45 -0800 (PST) Received: from pevele.eudil.fr (pevele.eudil.fr [193.48.57.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07191 for ; Wed, 5 Feb 2003 02:56:39 -0800 (PST) Received: from there (weppes.priv.eudil.fr [172.26.16.4]) by pevele.eudil.fr (8.11.3/jtpda-5.3.2) with SMTP id h15Auc926875 for ; Wed, 5 Feb 2003 11:56:38 +0100 Message-Id: <200302051056.h15Auc926875@pevele.eudil.fr> Content-Type: text/plain; charset="iso-8859-1" From: Gwenael Dewit Reply-To: gwenael.dewit@eudil.fr To: ipng@sunroof.eng.sun.com Subject: DNS and ipv6 Date: Wed, 5 Feb 2003 11:56:37 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! I am a french student working in an engineering school. My project is to migrate the network of my school in ipv6. My problem is when the router use autoconfiguration, I want to update my DNS... How could I do that ?? i thought about 2 solutions: - The router send message to my DNS to alert him that a new computer has a new ipv6 address. ( i m not sure that my cisco 3640 router can do that ) - use a DHCP to configure computers and update DNS, thus i would have to stop the process of autoconfiguration of my router... but is it possible to stop it??? Thanks for help!!!! Best regards. Gwenaël Dewit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 5 04:33:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15CX7Qb023669; Wed, 5 Feb 2003 04:33:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15CX6UZ023668; Wed, 5 Feb 2003 04:33:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15CX3Qb023661 for ; Wed, 5 Feb 2003 04:33:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15CXCVK025507 for ; Wed, 5 Feb 2003 04:33:12 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15719 for ; Wed, 5 Feb 2003 05:33:06 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h15CWph19933; Wed, 5 Feb 2003 13:32:51 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h15CViof065309; Wed, 5 Feb 2003 13:31:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302051231.h15CViof065309@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: gwenael.dewit@eudil.fr cc: ipng@sunroof.eng.sun.com Subject: Re: DNS and ipv6 In-reply-to: Your message of Wed, 05 Feb 2003 11:56:37 +0100. <200302051056.h15Auc926875@pevele.eudil.fr> Date: Wed, 05 Feb 2003 13:31: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 am a french student working in an engineering school. My project is to migrate the network of my school in ipv6. My problem is when the router use autoconfiguration, I want to update my DNS... How could I do that ?? i thought about 2 solutions: - The router send message to my DNS to alert him that a new computer has a new ipv6 address. ( i m not sure that my cisco 3640 router can do that ) - use a DHCP to configure computers and update DNS, thus i would have to stop the process of autoconfiguration of my router... but is it possible to stop it??? => a draft currently discussed in the DNSEXT WG mailing list proposes a solution: draft-ietf-dnsext-ipv6-name-auto-reg-00.txt 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 5 04:34:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15CYGQb023707; Wed, 5 Feb 2003 04:34:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15CYFth023706; Wed, 5 Feb 2003 04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15CYCQb023699 for ; Wed, 5 Feb 2003 04:34:12 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15CYMVL004616 for ; Wed, 5 Feb 2003 04:34:22 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07160 for ; Wed, 5 Feb 2003 04:34:16 -0800 (PST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15CZ52j016178; Wed, 5 Feb 2003 07:35:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-280.cisco.com [10.82.241.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA04278; Wed, 5 Feb 2003 07:34:11 -0500 (EST) Message-Id: <4.3.2.7.2.20030205070542.00b86200@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 07:34:08 -0500 To: john.loughney@nokia.com From: Ralph Droms Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I've reviewed the text in draft-ietf-ipv6-node-requirements-02.txt, and I have some comments about the text concerning DHCP. Regarding the use of DHCP for address assignment...RFC2462 is somewhat vague about the requirement - there are no RFC2119 words guiding the ues of DHCP in section 5.5.3, and no warnings about the consequences of not using DHCP when the 'M' bit is set. I think we should assume that DHCP is the stateful address assignment protocol at this point (esp. now that the spec has been accepted as a PS). Also, RFC2462 does not explicitly explain that stateless address autoconfiguration and the use of DHCP are independent - if the 'M' bit is set and there are prefix options in the RA, the host will obtain both SAAC and DHCP addresses. I propose the following text : 4.5.5 Stateful Address Autoconfiguration Stateful Address Autoconfiguration SHOULD be supported. DHCP [DHCPv6] is the standard stateful address configuration protocol. An IPv6 node that does not include an implementation of DHCP will be unable to obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). An IPv6 node that receives a router advertisement with the 'M' flag set and that contains advertised prefixes will configure interfaces with both stateless autoconfiguration addresses and addresses obtained through DHCP. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'M' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, this type of node is not required to initiate DHCP. Regarding the 'O' flag...RFC2462 uses about the same (non-RFC2119) words here as for the 'M' flag. Again, there is no mention of the consequences of not implementing the "stateful autoconfiguration protocol", and it's appropriate to assume DHCP will be stateful autoconfiguration protocol. So, I think section 5.3 should look a lot like 4.5.5: 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Stateful Autoconfiguration SHOULD be supported. DHCP [DHCPv6] is the standard stateful configuration protocol. An IPv6 node that does not include an implementation of DHCP will be unable to obtain other configuration information such as the addresses of DNS servers when it is connected to a link over which the node receives a router advertisement in which the 'O' flag ("Other stateful configuration") is set. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, this type of node is not required to initiate DHCP. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 5 05:24:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DOxQb024099; Wed, 5 Feb 2003 05:24:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15DOxYG024098; Wed, 5 Feb 2003 05:24:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DOuQb024091 for ; Wed, 5 Feb 2003 05:24:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15DP4VL012633 for ; Wed, 5 Feb 2003 05:25:04 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26210 for ; Wed, 5 Feb 2003 06:24:58 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 372C66A901; Wed, 5 Feb 2003 15:24:51 +0200 (EET) Message-ID: <3E411099.6080605@kolumbus.fi> Date: Wed, 05 Feb 2003 15:24:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <4.3.2.7.2.20030205070542.00b86200@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph Droms wrote: > John, > > I've reviewed the text in draft-ietf-ipv6-node-requirements-02.txt, and > I have some comments about the text concerning DHCP. > > Regarding the use of DHCP for address assignment...RFC2462 is somewhat > vague about the requirement - there are no RFC2119 words guiding the ues > of DHCP in section 5.5.3, and no warnings about the consequences of not > using DHCP when the 'M' bit is set. I think we should assume that DHCP Yes (though in defense of 2462 this is probably some "weasel wording" to get around the fact that at the time 2462 was written there was no RFC for DHCPv6). > is the stateful address assignment protocol at this point (esp. now that > the spec has been accepted as a PS). Also, RFC2462 does not explicitly > explain that stateless address autoconfiguration and the use of DHCP are > independent - if the 'M' bit is set and there are prefix options in the > RA, the host will obtain both SAAC and DHCP addresses. I propose the Yes. > following text : > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration SHOULD be supported. DHCP SHOULD or MAY? > [DHCPv6] is the standard stateful address configuration protocol. An > IPv6 node that does not include an implementation of DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). An IPv6 node that receives > a router advertisement with the 'M' flag set and that contains > advertised prefixes will configure interfaces with both stateless > autoconfiguration addresses and addresses obtained through DHCP. Looks good. > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set > (see section 5.5.3 of RFC2462). In addition, in the absence of a > router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. Ok. > For IPv6 Nodes that do not implement DHCP, the 'M' flag > of a Router Advertisement can be ignored. Furthermore, in the > absence of a router, this type of node is not required to initiate > DHCP. > > Regarding the 'O' flag...RFC2462 uses about the same (non-RFC2119) words > here as for the 'M' flag. Again, there is no mention of the > consequences of not implementing the "stateful autoconfiguration > protocol", and it's appropriate to assume DHCP will be stateful > autoconfiguration protocol. So, I think section 5.3 should look a lot > like 4.5.5: > > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > > Stateful Autoconfiguration SHOULD be supported. DHCP [DHCPv6] is > the standard stateful configuration protocol. An IPv6 node that does > not include an implementation of DHCP will be unable to obtain other > configuration information such as the addresses of DNS servers when > it is connected to a link over which the node receives a router > advertisement in which the 'O' flag ("Other stateful configuration") > is set. > > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'O' flag set > (see section 5.5.3 of RFC2462). In addition, in the absence of a > router, hosts that implement DHCP MUST attempt to use DHCP. > > For IPv6 Nodes that do not implement DHCP, the 'O' flag > of a Router Advertisement can be ignored. Furthermore, in the > absence of a router, this type of node is not required to initiate > DHCP. Looks good. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 5 05:30:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DUBQb024193; Wed, 5 Feb 2003 05:30:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15DUBK9024192; Wed, 5 Feb 2003 05:30:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DU8Qb024185 for ; Wed, 5 Feb 2003 05:30:08 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15DUHVK004181 for ; Wed, 5 Feb 2003 05:30:17 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01057 for ; Wed, 5 Feb 2003 05:30:10 -0800 (PST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h15DWmm23369 for ; Wed, 5 Feb 2003 15:32:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 15:30:08 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 15:30:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 15:30:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Wed, 5 Feb 2003 15:30:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLNEuWv33zInO52RtWbXpxKCFWH8AAB6rtQ To: Cc: X-OriginalArrivalTime: 05 Feb 2003 13:30:07.0983 (UTC) FILETIME=[B33E17F0:01C2CD1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h15DU8Qb024186 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Ralph, The text looks really good, what do other thinks? Does anyone have a preference for Stateful Address Autoconfiguration to be a SHOULD or a MAY? thanks, John > -----Original Message----- > From: ext Ralph Droms [mailto:rdroms@cisco.com] > Sent: 05 February, 2003 14:34 > To: Loughney John (NRC/Helsinki) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt > > > John, > > I've reviewed the text in > draft-ietf-ipv6-node-requirements-02.txt, and I > have some comments about the text concerning DHCP. > > Regarding the use of DHCP for address assignment...RFC2462 is > somewhat > vague about the requirement - there are no RFC2119 words > guiding the ues of > DHCP in section 5.5.3, and no warnings about the consequences > of not using > DHCP when the 'M' bit is set. I think we should assume that > DHCP is the > stateful address assignment protocol at this point (esp. now > that the spec > has been accepted as a PS). Also, RFC2462 does not > explicitly explain that > stateless address autoconfiguration and the use of DHCP are > independent - > if the 'M' bit is set and there are prefix options in the RA, > the host will > obtain both SAAC and DHCP addresses. I propose the following text : > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration SHOULD be supported. DHCP > [DHCPv6] is the standard stateful address configuration > protocol. An > IPv6 node that does not include an implementation of DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). An IPv6 node that receives > a router advertisement with the 'M' flag set and that contains > advertised prefixes will configure interfaces with both stateless > autoconfiguration addresses and addresses obtained through DHCP. > > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set > (see section 5.5.3 of RFC2462). In addition, in the absence of a > router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > For IPv6 Nodes that do not implement DHCP, the 'M' flag > of a Router Advertisement can be ignored. Furthermore, in the > absence of a router, this type of node is not required to initiate > DHCP. > > Regarding the 'O' flag...RFC2462 uses about the same > (non-RFC2119) words > here as for the 'M' flag. Again, there is no mention of the > consequences > of not implementing the "stateful autoconfiguration > protocol", and it's > appropriate to assume DHCP will be stateful autoconfiguration > protocol. So, I think section 5.3 should look a lot like 4.5.5: > > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > > Stateful Autoconfiguration SHOULD be supported. DHCP [DHCPv6] is > the standard stateful configuration protocol. An IPv6 node > that does > not include an implementation of DHCP will be unable to > obtain other > configuration information such as the addresses of DNS servers when > it is connected to a link over which the node receives a router > advertisement in which the 'O' flag ("Other stateful > configuration") > is set. > > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'O' flag set > (see section 5.5.3 of RFC2462). In addition, in the absence of a > router, hosts that implement DHCP MUST attempt to use DHCP. > > For IPv6 Nodes that do not implement DHCP, the 'O' flag > of a Router Advertisement can be ignored. Furthermore, in the > absence of a router, this type of node is not required to initiate > DHCP. > > - Ralph > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 5 05:56:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DuJQb024661; Wed, 5 Feb 2003 05:56:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15DuJSH024660; Wed, 5 Feb 2003 05:56:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DuFQb024653 for ; Wed, 5 Feb 2003 05:56:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15DuPVK008320 for ; Wed, 5 Feb 2003 05:56:25 -0800 (PST) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15580 for ; Wed, 5 Feb 2003 05:56:19 -0800 (PST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h15Dsro7026637; Wed, 5 Feb 2003 08:54:53 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 5 Feb 2003 08:57:13 -0500 Message-ID: <3E4117F5.2060802@nc.rr.com> Date: Wed, 05 Feb 2003 08:56:05 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Hi Ralph, > > The text looks really good, what do other thinks? Does anyone > have a preference for Stateful Address Autoconfiguration to be > a SHOULD or a MAY? I tend to agree with the SHOULD. Since these nodes recognize the 'M' & 'O' bit-settings, they should be capable of acting on their settings. 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 Wed Feb 5 05:58:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DwJQb024713; Wed, 5 Feb 2003 05:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15DwJaB024712; Wed, 5 Feb 2003 05:58:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15DwFQb024705 for ; Wed, 5 Feb 2003 05:58:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15DwOVL018286 for ; Wed, 5 Feb 2003 05:58:24 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11624 for ; Wed, 5 Feb 2003 06:58:19 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h15DwIoP017434 for ; Wed, 5 Feb 2003 08:58:18 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h15DwG81129856 for ; Wed, 5 Feb 2003 06:58:17 -0700 Importance: Normal Sensitivity: Subject: new RFC2011 MIB draft and InetZoneIndex from INET-ADDRESS-MIB To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Wed, 5 Feb 2003 08:58:15 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/05/2003 06:58:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The newest version of the RFC2011 draft uses textual convention InetZoneIndex from the INET-ADDRESS-MIB. Is there a new internet draft for the INET-ADDRESS-MIB that updates the version in RFC3291 and contains the definition of InetZoneIndex? Sorry if I missed notification about this new draft on the mailing list. Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 5 07:11:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15FBLQb025174; Wed, 5 Feb 2003 07:11:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15FBLZ6025173; Wed, 5 Feb 2003 07:11:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15FBIQb025166 for ; Wed, 5 Feb 2003 07:11:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15FBRVL002004 for ; Wed, 5 Feb 2003 07:11:27 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03805 for ; Wed, 5 Feb 2003 07:11:21 -0800 (PST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h15FBCh23901; Wed, 5 Feb 2003 16:11:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h15FA6of065953; Wed, 5 Feb 2003 16:10:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302051510.h15FA6of065953@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Ralph Droms , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-reply-to: Your message of Wed, 05 Feb 2003 15:24:41 +0200. <3E411099.6080605@kolumbus.fi> Date: Wed, 05 Feb 2003 16:10:06 +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: > following text : > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration SHOULD be supported. DHCP SHOULD or MAY? => I agree, a MAY is enough. 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 5 11:23:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15JN0Qb025885; Wed, 5 Feb 2003 11:23:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15JN0QK025884; Wed, 5 Feb 2003 11:23:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15JMuQb025877 for ; Wed, 5 Feb 2003 11:22:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15JN5VK011801 for ; Wed, 5 Feb 2003 11:23:06 -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 MAA05219 for ; Wed, 5 Feb 2003 12:23:00 -0700 (MST) Received: from nsh-opal.windriver.com ([147.11.38.222]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA07994; Wed, 5 Feb 2003 11:21:51 -0800 (PST) Message-Id: <5.1.0.14.2.20030205112133.0244aec0@mail.wrs.com> X-Sender: routhier@mail.wrs.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Feb 2003 11:23:36 -0800 To: adamson@us.ibm.com, ipng@sunroof.eng.sun.com From: "Shawn A. Routhier" Subject: Re: new RFC2011 MIB draft and InetZoneIndex from INET-ADDRESS-MIB In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The INET-ADDRESS-MIB has not been updated to include InetZoneIndex yet. One of the authors of the MIB is looking into the update and hopes to have something done soon. At 08:58 AM 2/5/03 -0500, Kristine Adamson wrote: >The newest version of the RFC2011 draft uses textual convention >InetZoneIndex from the INET-ADDRESS-MIB. Is there a new internet draft for >the INET-ADDRESS-MIB that updates the version in RFC3291 and contains the >definition of InetZoneIndex? Sorry if I missed notification about this new >draft on the mailing list. > >Thanks, > >Kristine Adamson >IBM Communications Server for MVS: TCP/IP Development >Internet e-mail:adamson@us.ibm.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 >-------------------------------------------------------------------- Shawn A. Routhier SMTS Wind River Networks Business Unit 510 749 2095 office 510 749 2560 fax www.windriver.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 5 13:17:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15LHwQb026172; Wed, 5 Feb 2003 13:17:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h15LHvxc026171; Wed, 5 Feb 2003 13:17:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h15LHsQb026164 for ; Wed, 5 Feb 2003 13:17:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h15LI3VL022813 for ; Wed, 5 Feb 2003 13:18:03 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15714 for ; Wed, 5 Feb 2003 14:17:57 -0700 (MST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15LIlUo000602; Wed, 5 Feb 2003 16:18:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12487; Wed, 5 Feb 2003 16:17:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 16:17:49 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 5 19:08:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1638aQb026812; Wed, 5 Feb 2003 19:08:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1638am8026811; Wed, 5 Feb 2003 19:08:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1638WQb026802 for ; Wed, 5 Feb 2003 19:08:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1638gVK008482 for ; Wed, 5 Feb 2003 19:08:42 -0800 (PST) Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03764 for ; Wed, 5 Feb 2003 19:08:36 -0800 (PST) Received: from Rich3800@aol.com by imo-d09.mx.aol.com (mail_out_v34.21.) id 1.130.1aa22e17 (15877) for ; Wed, 5 Feb 2003 22:08:18 -0500 (EST) Received: from aol.com ([12.108.37.109]) by air-id07.mx.aol.com (v90_r2.5) with ESMTP id MAILINID74-0205220818; Wed, 05 Feb 2003 22:08:18 -0500 Message-ID: <3E41D05A.6080903@aol.com> Date: Wed, 05 Feb 2003 22:02:50 -0500 From: Rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Home network setup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have a home network made up of 2 PCs (hers is Win XP, mine is Linux 2.4-based) sharing a cable modem Internet connection. The cable modem connects to a SpeedStream NAT/router I want to replace the NAT router with a device (a PC) that will enable me to host an IPv4/v6 Apache web server for people on the Internet from my Linux PC. I have a spare PC on which I can install the necessary software to enable the routing connectivity necessary. I get one dynamic address from my ISP. How can one IPv4 IP address be shared between 2 PCs without a NAT? Thank you. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 01:00:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1690tQb028263; Thu, 6 Feb 2003 01:00:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1690sLC028262; Thu, 6 Feb 2003 01:00:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1690pQb028255 for ; Thu, 6 Feb 2003 01:00:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1690xVL027050 for ; Thu, 6 Feb 2003 01:00:59 -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 CAA24688 for ; Thu, 6 Feb 2003 02:00:53 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1690df18991; Thu, 6 Feb 2003 11:00:39 +0200 Date: Thu, 6 Feb 2003 11:00:38 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Feb 2003, Ralph Droms wrote: > DHCPv6" . The last call will > conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List option. > This document is being considered for Proposed Standard as an extension > to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt A few comments; I haven't looked too deep into DHCPv6 to be able to comment on those parts, but there are some definite need for revisal in the doc..: 2. Requirements The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, [...] ==> I'd put these under Introduction or Terminology sections, no use having a separate section with a questionable title. option-length: Length of the 'options' field in octets; must be a multiple of 16 ==> 'options' field has not been defined. Is it the whole option or just the length of DNS-server address options (I assume so)? If the former, there must be 32 bits of zero padding. Is it ok that the options aren't 64-bit aligned? The list of domain names in the 'searchstring' MUST be encoded as specified in section "Representation and use of domain names" of the DHCPv6 specification [4]. ==> I didn't bother to check, but I guess this document also defines how to pad the names to get some desired level of alignment? 6. Appearance of these options The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. The Domain Search List option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. ==> I would reword these differently, like: The Domain Name Server option MUST NOT appear in other than the following messages: .... ==> is it ok to server to give only one of these options but not the other? References ==> split the references [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February 2002. ==> update this draft version Author's Address Ralph Droms (ed.) ==> the author is an editor, but the draft does not have acknowledgements or contributors section. Just remove Editor if nobody else contributed to the document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 02:53:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16ArHQb028491; Thu, 6 Feb 2003 02:53:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16ArHTa028490; Thu, 6 Feb 2003 02:53:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16ArEQb028483 for ; Thu, 6 Feb 2003 02:53:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16ArMVL012747 for ; Thu, 6 Feb 2003 02:53:22 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07573 for ; Thu, 6 Feb 2003 02:53:16 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h16Apu89029122; Thu, 6 Feb 2003 11:52:03 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h16ApemR125120; Thu, 6 Feb 2003 11:51:40 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28762 from ; Thu, 6 Feb 2003 11:51:38 +0100 Message-Id: <3E423E0B.3C60ECB0@hursley.ibm.com> Date: Thu, 06 Feb 2003 11:50:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Brian Haberman Cc: john.loughney@nokia.com, rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <3E4117F5.2060802@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Haberman wrote: > > john.loughney@nokia.com wrote: > > Hi Ralph, > > > > The text looks really good, what do other thinks? Does anyone > > have a preference for Stateful Address Autoconfiguration to be > > a SHOULD or a MAY? > > I tend to agree with the SHOULD. Since these nodes recognize the > 'M' & 'O' bit-settings, they should be capable of acting on their > settings. > > Brian Does that follow? DHCP strikes me very much as a discretionary thing. I think vendors will know when to support it, so a MAY seems enough to me. other 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 Thu Feb 6 03:26:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16BQgQb028646; Thu, 6 Feb 2003 03:26:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16BQgsD028645; Thu, 6 Feb 2003 03:26:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16BQcQb028638 for ; Thu, 6 Feb 2003 03:26:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16BQmVL017296 for ; Thu, 6 Feb 2003 03:26:48 -0800 (PST) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28409 for ; Thu, 6 Feb 2003 03:26:42 -0800 (PST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h16BPHo5005052; Thu, 6 Feb 2003 06:25:17 -0500 (EST) Received: from nc.rr.com ([24.162.252.243]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 6 Feb 2003 06:27:39 -0500 Message-ID: <3E4245DF.6040300@nc.rr.com> Date: Thu, 06 Feb 2003 06:24:15 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: john.loughney@nokia.com, rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <3E4117F5.2060802@nc.rr.com> <3E423E0B.3C60ECB0@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Brian Haberman wrote: > >>john.loughney@nokia.com wrote: >> >>>Hi Ralph, >>> >>>The text looks really good, what do other thinks? Does anyone >>>have a preference for Stateful Address Autoconfiguration to be >>>a SHOULD or a MAY? >> >>I tend to agree with the SHOULD. Since these nodes recognize the >>'M' & 'O' bit-settings, they should be capable of acting on their >>settings. >> >>Brian > > > Does that follow? DHCP strikes me very much as a discretionary > thing. I think vendors will know when to support it, so a MAY > seems enough to me. My concern is the scenario where an operator knowingly disables prefix advertisements and enables DHCPv6. If the nodes doesn't do DHCP, it is stuck with only the link-local address. 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 Thu Feb 6 04:31:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16CVMQb029146; Thu, 6 Feb 2003 04:31:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16CVMbg029145; Thu, 6 Feb 2003 04:31:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16CVJQb029138 for ; Thu, 6 Feb 2003 04:31:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16CVSVK007917 for ; Thu, 6 Feb 2003 04:31:28 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA17849 for ; Thu, 6 Feb 2003 05:31:22 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h16CQ3lo067598; Thu, 6 Feb 2003 13:26:04 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h16CQ0La128672; Thu, 6 Feb 2003 13:26:01 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34712 from ; Thu, 6 Feb 2003 13:25:51 +0100 Message-Id: <3E425420.D743186D@hursley.ibm.com> Date: Thu, 06 Feb 2003 13:25:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Brian Haberman Cc: john.loughney@nokia.com, rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <3E4117F5.2060802@nc.rr.com> <3E423E0B.3C60ECB0@hursley.ibm.com> <3E4245DF.6040300@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Haberman wrote: > > Brian E Carpenter wrote: > > Brian Haberman wrote: > > > >>john.loughney@nokia.com wrote: > >> > >>>Hi Ralph, > >>> > >>>The text looks really good, what do other thinks? Does anyone > >>>have a preference for Stateful Address Autoconfiguration to be > >>>a SHOULD or a MAY? > >> > >>I tend to agree with the SHOULD. Since these nodes recognize the > >>'M' & 'O' bit-settings, they should be capable of acting on their > >>settings. > >> > >>Brian > > > > > > Does that follow? DHCP strikes me very much as a discretionary > > thing. I think vendors will know when to support it, so a MAY > > seems enough to me. > > My concern is the scenario where an operator knowingly disables > prefix advertisements and enables DHCPv6. If the nodes doesn't > do DHCP, it is stuck with only the link-local address. Understood. That certainly deserves a health warning. But in large scale deployments of low-end devices, implementors need to feel free to leave DHCP out. Brian 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 Thu Feb 6 04:39:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16CdSQb029306; Thu, 6 Feb 2003 04:39:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16CdSmw029305; Thu, 6 Feb 2003 04:39:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16CdOQb029295 for ; Thu, 6 Feb 2003 04:39:24 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16CdYVL027973 for ; Thu, 6 Feb 2003 04:39:34 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08391 for ; Thu, 6 Feb 2003 04:39:27 -0800 (PST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16Cg6m08389 for ; Thu, 6 Feb 2003 14:42:06 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 14:39:23 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 14:39:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 14:39:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Thu, 6 Feb 2003 14:39:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLN26hA40aA9AgmTdmSUu6TsGB8jAAAI/yA To: , Cc: X-OriginalArrivalTime: 06 Feb 2003 12:39:19.0929 (UTC) FILETIME=[C4DFB690:01C2CDDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h16CdPQb029296 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian(s); > > My concern is the scenario where an operator knowingly disables > > prefix advertisements and enables DHCPv6. If the nodes doesn't > > do DHCP, it is stuck with only the link-local address. > > Understood. That certainly deserves a health warning. But in large > scale deployments of low-end devices, implementors need to feel > free to leave DHCP out. Just a small comment - 2462 (stateless aa) is a MUST. Additionally, manual configuration is always a possibility as well. If certain hosts know they don't need DHCP, then I don't see the problem of having DHCP as a MAY. In general, stateless address autoconfig is a good thing, so we want to encourage service providers to do the right thing. br, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 05:15:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DF8Qb029716; Thu, 6 Feb 2003 05:15:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16DF8o5029715; Thu, 6 Feb 2003 05:15:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DF5Qb029708 for ; Thu, 6 Feb 2003 05:15:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16DFEVK014347 for ; Thu, 6 Feb 2003 05:15:14 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28777 for ; Thu, 6 Feb 2003 05:15:09 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 09C366A901; Thu, 6 Feb 2003 15:15:08 +0200 (EET) Message-ID: <3E425FD1.4090701@kolumbus.fi> Date: Thu, 06 Feb 2003 15:14:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: brian@hursley.ibm.com, bkhabs@nc.rr.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Hi Brian(s); > > >>>My concern is the scenario where an operator knowingly disables >>>prefix advertisements and enables DHCPv6. If the nodes doesn't >>>do DHCP, it is stuck with only the link-local address. >> >>Understood. That certainly deserves a health warning. But in large >>scale deployments of low-end devices, implementors need to feel >>free to leave DHCP out. > > > Just a small comment - 2462 (stateless aa) is a MUST. Additionally, > manual configuration is always a possibility as well. If certain > hosts know they don't need DHCP, then I don't see the problem of > having DHCP as a MAY. > > In general, stateless address autoconfig is a good thing, so we want > to encourage service providers to do the right thing. Maybe the right thing is to attach a warning or an explanation about the implications and leave the support as a MAY. For instance, "Nodes that do not implement DHCP may become unable to communicate outside the link when their routers advertise stateful autoconfiguration and no prefixes suitable for stateless autoconfiguration are offered." 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 6 05:31:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DVkQb029851; Thu, 6 Feb 2003 05:31:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16DVkVa029850; Thu, 6 Feb 2003 05:31:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DVhQb029843 for ; Thu, 6 Feb 2003 05:31:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16DVqVL005648 for ; Thu, 6 Feb 2003 05:31:52 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13559 for ; Thu, 6 Feb 2003 06:31:46 -0700 (MST) From: juha.wiljakka@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16DUe224058 for ; Thu, 6 Feb 2003 15:30:40 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 15:31:45 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 15:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Thu, 6 Feb 2003 15:31:44 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3719@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLN4yR2u3ONlsxxRtyT4JuAh9BhlAAADjIQ To: , Cc: , , X-OriginalArrivalTime: 06 Feb 2003 13:31:45.0077 (UTC) FILETIME=[17873650:01C2CDE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h16DVhQb029844 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all! I support the proposal below & the idea having DHCPv6 support as a MAY. Best Regards, -Juha W.- -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 06 February, 2003 15:15 > In general, stateless address autoconfig is a good thing, so we want > to encourage service providers to do the right thing. Maybe the right thing is to attach a warning or an explanation about the implications and leave the support as a MAY. For instance, "Nodes that do not implement DHCP may become unable to communicate outside the link when their routers advertise stateful autoconfiguration and no prefixes suitable for stateless autoconfiguration are offered." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 05:37:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DbqQb029997; Thu, 6 Feb 2003 05:37:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16DbqIM029996; Thu, 6 Feb 2003 05:37:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DbnQb029989 for ; Thu, 6 Feb 2003 05:37:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16DbwVL006896 for ; Thu, 6 Feb 2003 05:37:58 -0800 (PST) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09832 for ; Thu, 6 Feb 2003 06:37:53 -0700 (MST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h16DaYo9018366; Thu, 6 Feb 2003 08:36:34 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 6 Feb 2003 08:38:55 -0500 Message-ID: <3E426529.6020502@nc.rr.com> Date: Thu, 06 Feb 2003 08:37:45 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: john.loughney@nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <3E425FD1.4090701@kolumbus.fi> In-Reply-To: <3E425FD1.4090701@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > john.loughney@nokia.com wrote: > >> Hi Brian(s); >> >> >>>> My concern is the scenario where an operator knowingly disables >>>> prefix advertisements and enables DHCPv6. If the nodes doesn't >>>> do DHCP, it is stuck with only the link-local address. >>> >>> >>> Understood. That certainly deserves a health warning. But in large >>> scale deployments of low-end devices, implementors need to feel >>> free to leave DHCP out. >> >> >> >> Just a small comment - 2462 (stateless aa) is a MUST. Additionally, >> manual configuration is always a possibility as well. If certain >> hosts know they don't need DHCP, then I don't see the problem of >> having DHCP as a MAY. >> In general, stateless address autoconfig is a good thing, so we want >> to encourage service providers to do the right thing. > > > Maybe the right thing is to attach a warning or an explanation > about the implications and leave the support as a MAY. For > instance, > > "Nodes that do not implement DHCP may become unable to > communicate outside the link when their routers advertise > stateful autoconfiguration and no prefixes suitable > for stateless autoconfiguration are offered." If that type of text is in the doc, I will support a MAY. 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 Thu Feb 6 05:49:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16Dn1Qb000328; Thu, 6 Feb 2003 05:49:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16Dn1ob000327; Thu, 6 Feb 2003 05:49:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16DmtQb000317 for ; Thu, 6 Feb 2003 05:48:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16Dn4VK020022 for ; Thu, 6 Feb 2003 05:49:04 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27256 for ; Thu, 6 Feb 2003 06:48:58 -0700 (MST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16Dnpt1015871 for ; Thu, 6 Feb 2003 08:49:51 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29557 for ; Thu, 6 Feb 2003 08:48:57 -0500 (EST) Message-Id: <4.3.2.7.2.20030206084628.00b84438@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 08:48:54 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: <3E425FD1.4090701@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, At 03:14 PM 2/6/2003 +0200, Jari Arkko wrote: [snip] >Maybe the right thing is to attach a warning or an explanation >about the implications and leave the support as a MAY. For >instance, > > "Nodes that do not implement DHCP may become unable to > communicate outside the link when their routers advertise > stateful autoconfiguration and no prefixes suitable > for stateless autoconfiguration are offered." > >Jari Do you suggest this text in addition to or replacing the following text from my original draft: An IPv6 node that does not include an implementation of DHCP will be unable to obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 06:24:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16EO0Qb000887; Thu, 6 Feb 2003 06:24:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16ENxx1000886; Thu, 6 Feb 2003 06:23:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16ENtQb000879 for ; Thu, 6 Feb 2003 06:23:56 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16EO4VK000109 for ; Thu, 6 Feb 2003 06:24:04 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06677 for ; Thu, 6 Feb 2003 06:23:58 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 73B316A902; Thu, 6 Feb 2003 16:23:57 +0200 (EET) Message-ID: <3E426FF2.1060706@kolumbus.fi> Date: Thu, 06 Feb 2003 16:23:46 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <4.3.2.7.2.20030206084628.00b84438@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, your text is fine. I didn't realize you already had it there. Anyway, as long as a note roughly with the contents we have been discussing appears, I'm OK with it... Jari > Do you suggest this text in addition to or replacing the following text > from my original draft: > > An > IPv6 node that does not include an implementation of DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). > > - Ralph > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 6 06:33:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16EXIQb001005; Thu, 6 Feb 2003 06:33:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16EXIhU001004; Thu, 6 Feb 2003 06:33:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16EXEQb000993 for ; Thu, 6 Feb 2003 06:33:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16EXNVL016260 for ; Thu, 6 Feb 2003 06:33:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07545 for ; Thu, 6 Feb 2003 07:33:17 -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 JAA19029; Thu, 6 Feb 2003 09:29:37 -0500 (EST) Message-Id: <200302061429.JAA19029@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-unicast-aggr-v2-01.txt Date: Thu, 06 Feb 2003 09:29:37 -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 Global Unicast Address Format for the 2000::/3 Prefix Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-unicast-aggr-v2-01.txt Pages : 4 Date : 2003-2-5 This document defines the unicast address format for the 2000::/3 (001 binary) prefix. The address format defined in this document is consistent with RFC1883 'Internet Protocol, Version 6 (IPv6) Specification' and RFCXXXX 'IP Version 6 Addressing Architecture'. This documented replaces RFC2374 'An IPv6 Aggregatable Global Unicast Address Format'. RFC2374 will become historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-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-ietf-ipv6-unicast-aggr-v2-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-ietf-ipv6-unicast-aggr-v2-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: <2003-2-5140230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unicast-aggr-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5140230.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 6 07:18:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16FI3Qb001327; Thu, 6 Feb 2003 07:18:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16FI3s5001326; Thu, 6 Feb 2003 07:18:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16FHxQb001317 for ; Thu, 6 Feb 2003 07:17:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16FI8VL026228 for ; Thu, 6 Feb 2003 07:18:08 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15484 for ; Thu, 6 Feb 2003 08:18:03 -0700 (MST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16FIteM028175 for ; Thu, 6 Feb 2003 10:18:55 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05652 for ; Thu, 6 Feb 2003 10:18:01 -0500 (EST) Message-Id: <4.3.2.7.2.20030206101235.00b99e88@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 10:17:58 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: <3E426FF2.1060706@kolumbus.fi> References: <4.3.2.7.2.20030206084628.00b84438@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari - I liked the way your text was explicit about the consequences of not obtaining a global address through DHCP when no stateless autoconfig prefixes are advertised: Nodes that do not implement DHCP may become unable to communicate outside the link when their routers advertise stateful autoconfiguration and no prefixes suitable for stateless autoconfiguration are offered. Not knowing the background of all readers of the doc, it might be good to put your explicit warning in the text: An IPv6 node that does not include an implementation of DHCP will be unable to obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). In this situation, the IPv6 Node will be unable to communicate with other off-link nodes. And, I can live with MAY as long as this text is included. - Ralph At 04:23 PM 2/6/2003 +0200, you wrote: >Ralph, your text is fine. I didn't realize you already >had it there. Anyway, as long as a note roughly with >the contents we have been discussing appears, I'm OK >with it... > >Jari > >>Do you suggest this text in addition to or replacing the following text >>from my original draft: >> An >> IPv6 node that does not include an implementation of DHCP will be >> unable to obtain any IPv6 addresses aside from link-local addresses >> when it is connected to a link over which it receives a router >> advertisement with the 'M' flag (Managed address configuration) set >> and which contains no prefixes advertised for Stateless Address >> Autoconfiguration (see section 4.5.2). >>- Ralph >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home 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 6 07:21:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16FLTQb001492; Thu, 6 Feb 2003 07:21:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16FLTFl001491; Thu, 6 Feb 2003 07:21:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16FLPQb001476 for ; Thu, 6 Feb 2003 07:21:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16FLYVL027252 for ; Thu, 6 Feb 2003 07:21:35 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24508 for ; Thu, 6 Feb 2003 08:21:28 -0700 (MST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16FKM219522 for ; Thu, 6 Feb 2003 17:20:22 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 17:21:27 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 17:21:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 17:21:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Thu, 6 Feb 2003 17:21:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLN8ySBYWs1mOuyQ3aPjOX7k1/OxgAAC+0g To: , X-OriginalArrivalTime: 06 Feb 2003 15:21:25.0852 (UTC) FILETIME=[69F9C9C0:01C2CDF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h16FLQQb001478 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, > Not knowing the background of all readers of the doc, it > might be good to put your explicit warning in the text: > > An IPv6 node that does not include an implementation of DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). In this situation, the IPv6 > Node will be unable to communicate with other off-link nodes. > > And, I can live with MAY as long as this text is included. That then is starting to sound like consensus. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 11:11:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16JBWQb003564; Thu, 6 Feb 2003 11:11:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16JBW7W003563; Thu, 6 Feb 2003 11:11:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16JBSQb003553 for ; Thu, 6 Feb 2003 11:11:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16JBbVL011929 for ; Thu, 6 Feb 2003 11:11:37 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21175 for ; Thu, 6 Feb 2003 12:11:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Feb 2003 19:11:31 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Feb 2003 19:11:31 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Feb 2003 19:11:30 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Feb 2003 19:11:30 Z Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt Date: Thu, 6 Feb 2003 11:11:29 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54BC3@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: x-mimeole: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt Thread-Index: AcLLlhasLz51Ld32TMqmCcP0hk63jACeaDTA From: "Michel Py" To: "Brian Carpenter" , "Bob Hinden" Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I say, ship it. If the RFC number could be consecutive to the one to be assigned to draft-ietf-ipngwg-addr-arch-v3-11.txt same as 2373/2374 it would be nice if it does not delay the process. Although the suppression of the documentation prefix is a worthy trade-off for speed of publication, it does not suppress the need for a documentation prefix RFC IMHO, even if some RIRs have or will allocate one on their own. As many other people, I was not aware of the APNIC prefix, and did like 2000:0001::/32 as it is something that my feeble brain can remember. 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 6 12:23:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16KN4Qb004001; Thu, 6 Feb 2003 12:23:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16KN4A6004000; Thu, 6 Feb 2003 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16KN1Qb003993 for ; Thu, 6 Feb 2003 12:23:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16KNAVK017044 for ; Thu, 6 Feb 2003 12:23:10 -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 NAA07349 for ; Thu, 6 Feb 2003 13:23:04 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h16KMqJ23410; Thu, 6 Feb 2003 22:22:52 +0200 Date: Thu, 6 Feb 2003 22:22:52 +0200 (EET) From: Pekka Savola To: Michel Py cc: Brian Carpenter , Bob Hinden , Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BC3@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 Thu, 6 Feb 2003, Michel Py wrote: > I say, ship it. Agree. > If the RFC number could be consecutive to the one to be > assigned to draft-ietf-ipngwg-addr-arch-v3-11.txt same as 2373/2374 it > would be nice if it does not delay the process. Surely it can, as this one cannot be published before draft-ietf-ipngwg-addr-arch-v3-11.txt is published. > Although the suppression of the documentation prefix is a worthy > trade-off for speed of publication, it does not suppress the need for a > documentation prefix RFC IMHO, even if some RIRs have or will allocate > one on their own. Agree. > As many other people, I was not aware of the APNIC > prefix, and did like 2000:0001::/32 as it is something that my feeble > brain can remember. Agree. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 6 13:16:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16LGWQb004222; Thu, 6 Feb 2003 13:16:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16LGVi6004221; Thu, 6 Feb 2003 13:16:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16LGRQb004214 for ; Thu, 6 Feb 2003 13:16:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16LGaVL023726 for ; Thu, 6 Feb 2003 13:16:36 -0800 (PST) Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13073 for ; Thu, 6 Feb 2003 14:16:31 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9W00GLHOFICG@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 06 Feb 2003 14:16:31 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9W00CWWOFIJK@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 06 Feb 2003 14:16:30 -0700 (MST) Date: Thu, 06 Feb 2003 13:16:29 -0800 From: Alain Durand Subject: Re: Documentation Prefix To: Bob Hinden , ipng@sunroof.eng.sun.com Message-id: <3E42D0AD.5050305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030203092405.032fe968@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, There are some unanswered questions about this APNIC prefix: 1- Can people who are not member of APNIC use this prefix? 2- How do people who are not APNIC members know about this prefix? i.e. how an implementor familiar with the RFC series but unaware of APNIC documents will know that such a prefix has been reserved? 3- What about the other RIRs? Are they going to recommend to use this prefix or are they going to reserve some others? Perhaps a separate very short Informatinal RFC pointing to a common RIR policy (once/if established) will help. - Alain. Bob Hinden wrote: > Patrick Grossetete just pointed out to me that there is already a > prefix allocated (by APNIC) for documentation. It is: > > 2001:0DB8::/32 > > For more details see: > > http://www.apnic.org/info/faq/ipv6-documentation-prefix-faq.html#3 > > Since I don't think we need two, I will remove the one I proposed from > and submit a new draft. > > 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 Thu Feb 6 16:34:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h170YoQb005190; Thu, 6 Feb 2003 16:34:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h170Yn3P005189; Thu, 6 Feb 2003 16:34:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h170YkQb005179 for ; Thu, 6 Feb 2003 16:34:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h170YtVL000716 for ; Thu, 6 Feb 2003 16:34:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17691 for ; Thu, 6 Feb 2003 16:34:50 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 00:29:24 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 00:27:53 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 00:27:52 Z Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 00:27:52 Z Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h170RpKI035424 for ; Thu, 6 Feb 2003 19:27:52 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h170RoxM082578 for ; Thu, 6 Feb 2003 17:27:51 -0700 Importance: Normal Sensitivity: Subject: IPv6 MIB team - is a new RFC2011 draft coming soon? To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-Id: From: Kristine Adamson Date: Thu, 6 Feb 2003 19:27:49 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/06/2003 17:27:50 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looks like MIB object ipv6IntefaceReachableTime is still spelled incorrectly in the November version of this draft. It should be ipv6Inte_r_faceReachableTime. Will there be a new version of the RFC2011 draft before the March IETF? Are new versions of the RFC2012 and RFC2096 drafts planned to be released anytime soon? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 6 17:00:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17107Qb005535; Thu, 6 Feb 2003 17:00:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17107xX005534; Thu, 6 Feb 2003 17:00:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17104Qb005527 for ; Thu, 6 Feb 2003 17:00:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1710DVL009109 for ; Thu, 6 Feb 2003 17:00:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26606 for ; Thu, 6 Feb 2003 17:00:07 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 01:00:06 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Fri, 7 Feb 2003 00:59:10 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 7 Feb 2003 01:00:05 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP; Fri, 7 Feb 2003 01:00:05 Z 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 RAA26279; Thu, 6 Feb 2003 17:00:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h17102S17288; Thu, 6 Feb 2003 17:00:02 -0800 X-mProtect: <200302070100> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrNOxCe; Thu, 06 Feb 2003 17:00:00 PST Message-Id: <4.3.2.7.2.20030206155424.02fa2738@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 16:59:41 -0800 To: Alain Durand From: Bob Hinden Subject: Re: Documentation Prefix Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E42D0AD.5050305@sun.com> References: <4.3.2.7.2.20030203092405.032fe968@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, >There are some unanswered questions about this APNIC prefix: >1- Can people who are not member of APNIC use this prefix? I don't see why not as it isn't supposed to be routed. >2- How do people who are not APNIC members know about this prefix? > i.e. how an implementor familiar with the RFC series but unaware > of APNIC documents will know that such a prefix has been reserved? Good question. I wasn't aware of it until Patrick Grossetete pointed it out to me. >3- What about the other RIRs? Are they going to recommend to use > this prefix or are they going to reserve some others? I would hope there would only be one assignment by the RIRs. It would be ironic if after all this time of trying to get a prefix for documentation, we get several :-) >Perhaps a separate very short Informatinal RFC pointing to >a common RIR policy (once/if established) will help. I will forward you email to Paul Wilson at APNIC. I think that what APNIC did was well intended, it might have been better if the IANA had done the allocation as it is not a regional issue and it might have been better to pick a prefix that was not in the middle of other assignments. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 6 19:02:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1732EQb006111; Thu, 6 Feb 2003 19:02:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1732EiY006110; Thu, 6 Feb 2003 19:02:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1732AQb006103 for ; Thu, 6 Feb 2003 19:02:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1732KVL011070 for ; Thu, 6 Feb 2003 19:02:20 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00991 for ; Thu, 6 Feb 2003 20:02:14 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 03:02:11 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 03:02:02 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 03:02:01 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Feb 2003 03:02:01 Z Received: from nsh-opal.windriver.com ([147.11.38.222]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA13003; Thu, 6 Feb 2003 19:00:51 -0800 (PST) Message-Id: <5.1.0.14.2.20030206190005.02450040@mail.wrs.com> X-Sender: routhier@mail.wrs.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 19:03:00 -0800 To: Kristine Adamson , ipng@sunroof.eng.sun.com From: "Shawn A. Routhier" Subject: Re: IPv6 MIB team - is a new RFC2011 draft coming soon? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've submitted the latest version of the RFC2011 update as an internet draft. I'm not sure how long it will take before the ID is released, hopefully it will be a fairly short time period. At 07:27 PM 2/6/03 -0500, Kristine Adamson wrote: >Looks like MIB object ipv6IntefaceReachableTime is still spelled >incorrectly in the November version of this draft. It should be >ipv6Inte_r_faceReachableTime. Will there be a new version of the RFC2011 >draft before the March IETF? Are new versions of the RFC2012 and RFC2096 >drafts planned to be released anytime soon? > >Thanks, > >Kristine Adamson >IBM Communications Server for MVS: TCP/IP Development >Internet e-mail:adamson@us.ibm.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 >-------------------------------------------------------------------- Shawn A. Routhier SMTS Wind River Networks Business Unit 510 749 2095 office 510 749 2560 fax www.windriver.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 7 00:48:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h178m5Qb007076; Fri, 7 Feb 2003 00:48:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h178m5VL007075; Fri, 7 Feb 2003 00:48:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h178m1Qb007068 for ; Fri, 7 Feb 2003 00:48:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h178mBVL010102 for ; Fri, 7 Feb 2003 00:48:11 -0800 (PST) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01153; Fri, 7 Feb 2003 01:48:02 -0700 (MST) Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h178kOut025001; Fri, 7 Feb 2003 09:46:24 +0100 (MET) Received: from PGROSSET-W2K.cisco.com (sjc-vpn3-402.cisco.com [10.21.65.146]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA07488; Fri, 7 Feb 2003 09:47:56 +0100 (MET) Message-Id: <4.3.2.7.2.20030207094717.0166a068@europe.cisco.com> X-Sender: pgrosset@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Feb 2003 09:47:54 +0100 To: Bob Hinden From: Patrick Grossetete Subject: Re: Documentation Prefix Cc: Alain Durand , ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030206155424.02fa2738@mailhost.iprg.nokia.com> References: <3E42D0AD.5050305@sun.com> <4.3.2.7.2.20030203092405.032fe968@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 I sent several requests to IANA but never got an answer, neither an acknowledgement... Patrick At 04:59 PM 06-02-03 -0800, Bob Hinden wrote: >Alain, > >>There are some unanswered questions about this APNIC prefix: >>1- Can people who are not member of APNIC use this prefix? > >I don't see why not as it isn't supposed to be routed. > >>2- How do people who are not APNIC members know about this prefix? >> i.e. how an implementor familiar with the RFC series but unaware >> of APNIC documents will know that such a prefix has been reserved? > >Good question. I wasn't aware of it until Patrick Grossetete pointed it >out to me. > >>3- What about the other RIRs? Are they going to recommend to use >> this prefix or are they going to reserve some others? > >I would hope there would only be one assignment by the RIRs. It would be >ironic if after all this time of trying to get a prefix for documentation, >we get several :-) > >>Perhaps a separate very short Informatinal RFC pointing to >>a common RIR policy (once/if established) will help. > >I will forward you email to Paul Wilson at APNIC. I think that what APNIC >did was well intended, it might have been better if the IANA had done the >allocation as it is not a regional issue and it might have been better to >pick a prefix that was not in the middle of other assignments. > >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 >-------------------------------------------------------------------- ____________________________________________ Patrick Grossetete Cisco Systems Internet Technology Division (ITD) - Product Manager Phone/Vmail: 33.1.58.04.61.52 Fax: 33.1.58.04.61.00 mobile: 33.6.19.98.51.31 Email:pgrosset@cisco.com 11 Rue Camille Desmoulins 92782 Issy les Moulineaux Cedex 9 France ____________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 7 04:21:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CLqQb007649; Fri, 7 Feb 2003 04:21:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17CLqST007648; Fri, 7 Feb 2003 04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CLmQb007641 for ; Fri, 7 Feb 2003 04:21:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17CLvVL011873 for ; Fri, 7 Feb 2003 04:21:57 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18284; Fri, 7 Feb 2003 04:21:51 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h17CLOlo072658; Fri, 7 Feb 2003 13:21:24 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h17CLNRg190194; Fri, 7 Feb 2003 13:21:23 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18286 from ; Fri, 7 Feb 2003 13:21:21 +0100 Message-Id: <3E43A492.5592122E@hursley.ibm.com> Date: Fri, 07 Feb 2003 13:20:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Patrick Grossetete Cc: Bob Hinden , Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Documentation Prefix References: <3E42D0AD.5050305@sun.com> <4.3.2.7.2.20030203092405.032fe968@mailhost.iprg.nokia.com> <4.3.2.7.2.20030207094717.0166a068@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not surprised. For something at this level I would recommend having the IAB write to IANA, if we end up needing IANA action. But if the various RIRs are in agreement about this, I think we are OK. Brian Patrick Grossetete wrote: > > I sent several requests to IANA but never got an answer, neither > an acknowledgement... > > Patrick > > At 04:59 PM 06-02-03 -0800, Bob Hinden wrote: > >Alain, > > > >>There are some unanswered questions about this APNIC prefix: > >>1- Can people who are not member of APNIC use this prefix? > > > >I don't see why not as it isn't supposed to be routed. > > > >>2- How do people who are not APNIC members know about this prefix? > >> i.e. how an implementor familiar with the RFC series but unaware > >> of APNIC documents will know that such a prefix has been reserved? > > > >Good question. I wasn't aware of it until Patrick Grossetete pointed it > >out to me. > > > >>3- What about the other RIRs? Are they going to recommend to use > >> this prefix or are they going to reserve some others? > > > >I would hope there would only be one assignment by the RIRs. It would be > >ironic if after all this time of trying to get a prefix for documentation, > >we get several :-) > > > >>Perhaps a separate very short Informatinal RFC pointing to > >>a common RIR policy (once/if established) will help. > > > >I will forward you email to Paul Wilson at APNIC. I think that what APNIC > >did was well intended, it might have been better if the IANA had done the > >allocation as it is not a regional issue and it might have been better to > >pick a prefix that was not in the middle of other assignments. > > > >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 > >-------------------------------------------------------------------- > > ____________________________________________ > Patrick Grossetete > Cisco Systems > Internet Technology Division (ITD) - Product Manager > > Phone/Vmail: 33.1.58.04.61.52 > Fax: 33.1.58.04.61.00 > mobile: 33.6.19.98.51.31 > Email:pgrosset@cisco.com > 11 Rue Camille Desmoulins > 92782 Issy les Moulineaux Cedex 9 > France -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 7 04:24:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CO8Qb007684; Fri, 7 Feb 2003 04:24:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17CO8NS007683; Fri, 7 Feb 2003 04:24:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CO5Qb007676 for ; Fri, 7 Feb 2003 04:24:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17CODVK028733 for ; Fri, 7 Feb 2003 04:24:13 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20054 for ; Fri, 7 Feb 2003 04:24:08 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h17CO1lo093972; Fri, 7 Feb 2003 13:24:01 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h17CO0Rg119698; Fri, 7 Feb 2003 13:24:01 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56016 from ; Fri, 7 Feb 2003 13:24:00 +0100 Message-Id: <3E43A530.3CB174B2@hursley.ibm.com> Date: Fri, 07 Feb 2003 13:23:12 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Thu, 6 Feb 2003, Michel Py wrote: > > I say, ship it. > > Agree. I say, WG Last Call it right away, so that it can be with the IESG before the IETF. 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 7 04:50:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CoRQb008197; Fri, 7 Feb 2003 04:50:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17CoRnW008196; Fri, 7 Feb 2003 04:50:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17CoOQb008189 for ; Fri, 7 Feb 2003 04:50:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17CoWVK002965 for ; Fri, 7 Feb 2003 04:50:32 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25975 for ; Fri, 7 Feb 2003 05:50:27 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h17CoCbt051508; Fri, 7 Feb 2003 13:50:12 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h17CoBRg190550; Fri, 7 Feb 2003 13:50:11 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33336 from ; Fri, 7 Feb 2003 13:50:10 +0100 Message-Id: <3E43AB53.449E09A@hursley.ibm.com> Date: Fri, 07 Feb 2003 13:49:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: john.loughney@nokia.com Cc: rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > > Ralph, > > > Not knowing the background of all readers of the doc, it > > might be good to put your explicit warning in the text: > > > > An IPv6 node that does not include an implementation of DHCP will be > > unable to obtain any IPv6 addresses aside from link-local addresses > > when it is connected to a link over which it receives a router > > advertisement with the 'M' flag (Managed address configuration) set > > and which contains no prefixes advertised for Stateless Address > > Autoconfiguration (see section 4.5.2). In this situation, the IPv6 > > Node will be unable to communicate with other off-link nodes. > > > > And, I can live with MAY as long as this text is included. > > That then is starting to sound like consensus. Agreed. Brian 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 Fri Feb 7 05:11:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17DBKQb008456; Fri, 7 Feb 2003 05:11:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17DBJVT008455; Fri, 7 Feb 2003 05:11:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17DBGQb008448 for ; Fri, 7 Feb 2003 05:11:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17DBOVK010848 for ; Fri, 7 Feb 2003 05:11:24 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20372 for ; Fri, 7 Feb 2003 05:11:19 -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 IAA08794; Fri, 7 Feb 2003 08:07:37 -0500 (EST) Message-Id: <200302071307.IAA08794@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-rfc2011-update-02.txt Date: Fri, 07 Feb 2003 08:07:37 -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 : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-02.txt Pages : 111 Date : 2003-2-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-02.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-rfc2011-update-02.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-rfc2011-update-02.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: <2003-2-6152537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-6152537.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 7 08:08:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17G8oQb009157; Fri, 7 Feb 2003 08:08:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17G8oGB009156; Fri, 7 Feb 2003 08:08:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17G8lQb009149 for ; Fri, 7 Feb 2003 08:08:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17G8tVK016691 for ; Fri, 7 Feb 2003 08:08:55 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08737 for ; Fri, 7 Feb 2003 09:08:50 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h17G8WBl042648; Fri, 7 Feb 2003 11:08:32 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h17G7FZZ132288; Fri, 7 Feb 2003 09:07:15 -0700 In-Reply-To: <4.3.2.7.2.20030206101235.00b99e88@funnel.cisco.com> To: Ralph Droms Cc: ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 02/07/2003 11:06:56 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 02/07/2003 11:06:56 AM, Serialize complete at 02/07/2003 11:06:56 AM, S/MIME Sign failed at 02/07/2003 11:06:56 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/07/2003 09:07:15, Serialize complete at 02/07/2003 09:07:15 Message-ID: Date: Fri, 7 Feb 2003 11:07:13 -0500 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not knowing the background of all readers of the doc, it might be good to > put your explicit warning in the text: > > An IPv6 node that does not include an implementation of DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). In this situation, the IPv6 > Node will be unable to communicate with other off-link nodes. This isn't strictly true - a node may use manually configured global or site-local IPv6 addresses and still be able to communicate with off-link nodes. Maybe the first sentence should be updated to indicate the node will not be able to dynamically obtain any IPv6 addresses, as an IPv6 may be statically assigned to a node, and the last sentence to indicate a node will require manual configuration in the absence of DHCP support when Stateless Address Autoconfiguration is not being used? Something like: An IPv6 node that does not include an implementation of DHCP will be unable to dynamically obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). In this situation, the IPv6 Node will be unable to communicate with other off-link nodes unless a global or site-local IPv6 address is manually configured. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 7 09:52:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17HqYQb010023; Fri, 7 Feb 2003 09:52:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17HqYZx010022; Fri, 7 Feb 2003 09:52:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17HqVQb010015 for ; Fri, 7 Feb 2003 09:52:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17HqdVL016381 for ; Fri, 7 Feb 2003 09:52:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15405 for ; Fri, 7 Feb 2003 10:52:33 -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 JAA25276; Fri, 7 Feb 2003 09:52:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h17HqWT13960; Fri, 7 Feb 2003 09:52:32 -0800 X-mProtect: <200302071752> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcr3wzK; Fri, 07 Feb 2003 09:52:30 PST Message-Id: <4.3.2.7.2.20030207095111.03246cd8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Feb 2003 09:52:11 -0800 To: Brian E Carpenter From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E43A530.3CB174B2@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have made a request (as the author) to the other co-chair to start a w.g. last call. Bob At 04:23 AM 2/7/2003, Brian E Carpenter wrote: >Pekka Savola wrote: > > > > On Thu, 6 Feb 2003, Michel Py wrote: > > > I say, ship it. > > > > Agree. > >I say, WG Last Call it right away, so that it can be with the IESG >before the IETF. > > 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 7 09:55:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17HtEQb010088; Fri, 7 Feb 2003 09:55:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17HtEGm010087; Fri, 7 Feb 2003 09:55:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17HtAQb010074 for ; Fri, 7 Feb 2003 09:55:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17HtIVL018658 for ; Fri, 7 Feb 2003 09:55:18 -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 KAA05469 for ; Fri, 7 Feb 2003 10:55:03 -0700 (MST) Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt Date: Fri, 7 Feb 2003 09:55:01 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9B2@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt Thread-Index: AcLOpGBP0E4dEbgKSvm7GIekU/fEfgALVs+g Content-class: urn:content-classes:message From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 To: "Brian Carpenter" , "Bob Hinden" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h17HtAQb010076 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > I say, WG Last Call it right away, so that it can be with > the IESG before the IETF. Indeed, this is what needs to be done. This one should be a no-brainer though. 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 7 10:04:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17I4MQb010410; Fri, 7 Feb 2003 10:04:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17I4M8k010409; Fri, 7 Feb 2003 10:04:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17I4JQb010402 for ; Fri, 7 Feb 2003 10:04:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17I4SVL026935 for ; Fri, 7 Feb 2003 10:04:28 -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 LAA00467 for ; Fri, 7 Feb 2003 11:04:22 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA17339 for ; Fri, 7 Feb 2003 10:03:14 -0800 (PST) Message-Id: <5.1.0.14.2.20030207125120.030dbba0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 12:58:51 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an IPv6 working group last call for comments on submitting the following document for consideration as a Proposed Standard RFC: Title : IPv6 Global Unicast Address Format for the 2000::/3 Prefix Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-unicast-aggr-v2-01.txt Pages : 4 Date : 4-Feb-03 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-01.txt This document will replace RFC2374 "An IPv6 Aggregatable Global Unicast Address Format", which is already a Proposed Standard RFC. RFC2374 will become historic. 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 21, 2003. Margaret Wasserman / Bob Hinden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 7 10:36:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17IaDQb010576; Fri, 7 Feb 2003 10:36:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17IaDk0010575; Fri, 7 Feb 2003 10:36:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17IaAQb010568 for ; Fri, 7 Feb 2003 10:36:10 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17IaJVK013527 for ; Fri, 7 Feb 2003 10:36:19 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27765 for ; Fri, 7 Feb 2003 10:36:13 -0800 (PST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h17Ib5Jr021396 for ; Fri, 7 Feb 2003 13:37:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21910 for ; Fri, 7 Feb 2003 13:36:11 -0500 (EST) Message-Id: <4.3.2.7.2.20030207133522.03eb4ef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Feb 2003 13:36:08 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: References: <4.3.2.7.2.20030206101235.00b99e88@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Roy - thanks for noticing the omission of manually configured addresses. Your revised text looks fine to me. - Ralph At 11:07 AM 2/7/2003 -0500, Roy Brabson wrote: > > Not knowing the background of all readers of the doc, it might be good >to > > put your explicit warning in the text: > > > > An IPv6 node that does not include an implementation of DHCP will be > > unable to obtain any IPv6 addresses aside from link-local addresses > > when it is connected to a link over which it receives a router > > advertisement with the 'M' flag (Managed address configuration) set > > and which contains no prefixes advertised for Stateless Address > > Autoconfiguration (see section 4.5.2). In this situation, the IPv6 > > Node will be unable to communicate with other off-link nodes. > >This isn't strictly true - a node may use manually configured global or >site-local IPv6 addresses and still be able to communicate with off-link >nodes. Maybe the first sentence should be updated to indicate the node >will not be able to dynamically obtain any IPv6 addresses, as an IPv6 may >be statically assigned to a node, and the last sentence to indicate a node >will require manual configuration in the absence of DHCP support when >Stateless Address Autoconfiguration is not being used? Something like: > > An IPv6 node that does not include an implementation of DHCP will be > unable to dynamically obtain any IPv6 addresses aside from > link-local addresses when it is connected to a link over which it > receives a router advertisement with the 'M' flag (Managed address > configuration) set and which contains no prefixes advertised for > Stateless Address Autoconfiguration (see section 4.5.2). In this > situation, the IPv6 Node will be unable to communicate with other > off-link nodes unless a global or site-local IPv6 address is > manually configured. > >Roy >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 7 23:03:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1873oQb014409; Fri, 7 Feb 2003 23:03:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1873oUi014408; Fri, 7 Feb 2003 23:03:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1873kQb014401 for ; Fri, 7 Feb 2003 23:03:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1873tVK020143 for ; Fri, 7 Feb 2003 23:03:55 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14020; Fri, 7 Feb 2003 23:03:50 -0800 (PST) Received: from philsmit-w2k01.cisco.com (ams-clip-vpn-dhcp27.cisco.com [10.61.64.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1873XB7016422; Fri, 7 Feb 2003 23:03:35 -0800 (PST) Message-Id: <5.1.0.14.2.20030208164708.03e2cec0@pfs-pc.cisco.com> X-Sender: philip@pfs-pc.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Feb 2003 17:03:29 +1000 To: Brian E Carpenter From: Philip Smith Subject: Re: Documentation Prefix Cc: Patrick Grossetete , Bob Hinden , Alain Durand , ipng@sunroof.eng.sun.com In-Reply-To: <3E43A492.5592122E@hursley.ibm.com> References: <3E42D0AD.5050305@sun.com> <4.3.2.7.2.20030203092405.032fe968@mailhost.iprg.nokia.com> <4.3.2.7.2.20030207094717.0166a068@europe.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, I proposed the documentation prefix as a policy proposal at the APNIC Open Policy Meeting in Kitakyushu last August. Seemed a logical place, given that the RIRs allocate address space, and APNIC is the RIR for the region I live and work in. The APNIC Policy Special Interest Group approved the proposal, and the member meeting agreed that the proposal should become APNIC policy. Following on from this, the documentation prefix became APNIC policy at the start of December. Both ARIN and the RIPE NCC indicated to me that should they get any requests for an IPv6 documentation prefix they will refer to the APNIC allocation (http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html). I don't think anyone sees regionalisation being a problem - it's simply one prefix which will be included in the IPv6 bogon filters ISPs currently implement. An internet-draft is currently "in the works", hopefully we can get this out asap; that should help with any awareness issues still left in the community. However, I do humbly apologise for not letting this working group know that the allocation had been made, a regrettable oversight in a very busy year end for me. :-( philip -- At 13:20 07/02/2003 +0100, Brian E Carpenter wrote: >I'm not surprised. For something at this level I >would recommend having the IAB write to IANA, if we >end up needing IANA action. But if the various RIRs >are in agreement about this, I think we are OK. > > Brian > >Patrick Grossetete wrote: > > > > I sent several requests to IANA but never got an answer, neither > > an acknowledgement... > > > > Patrick > > > > At 04:59 PM 06-02-03 -0800, Bob Hinden wrote: > > >Alain, > > > > > >>There are some unanswered questions about this APNIC prefix: > > >>1- Can people who are not member of APNIC use this prefix? > > > > > >I don't see why not as it isn't supposed to be routed. > > > > > >>2- How do people who are not APNIC members know about this prefix? > > >> i.e. how an implementor familiar with the RFC series but unaware > > >> of APNIC documents will know that such a prefix has been reserved? > > > > > >Good question. I wasn't aware of it until Patrick Grossetete pointed it > > >out to me. > > > > > >>3- What about the other RIRs? Are they going to recommend to use > > >> this prefix or are they going to reserve some others? > > > > > >I would hope there would only be one assignment by the RIRs. It would be > > >ironic if after all this time of trying to get a prefix for documentation, > > >we get several :-) > > > > > >>Perhaps a separate very short Informatinal RFC pointing to > > >>a common RIR policy (once/if established) will help. > > > > > >I will forward you email to Paul Wilson at APNIC. I think that what APNIC > > >did was well intended, it might have been better if the IANA had done the > > >allocation as it is not a regional issue and it might have been better to > > >pick a prefix that was not in the middle of other assignments. > > > > > >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 > > >-------------------------------------------------------------------- > > > > ____________________________________________ > > Patrick Grossetete > > Cisco Systems > > Internet Technology Division (ITD) - Product Manager > > > > Phone/Vmail: 33.1.58.04.61.52 > > Fax: 33.1.58.04.61.00 > > mobile: 33.6.19.98.51.31 > > Email:pgrosset@cisco.com > > 11 Rue Camille Desmoulins > > 92782 Issy les Moulineaux Cedex 9 > > France >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Mon Feb 10 06:02:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AE2TQb022855; Mon, 10 Feb 2003 06:02:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AE2TkK022854; Mon, 10 Feb 2003 06:02:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AE2QQb022847 for ; Mon, 10 Feb 2003 06:02:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AE2ZVK014832 for ; Mon, 10 Feb 2003 06:02:35 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07212 for ; Mon, 10 Feb 2003 06:02:28 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE3WhE024080; Mon, 10 Feb 2003 15:03:33 +0100 (CET) Date: Mon, 10 Feb 2003 09:17:55 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BB9@server2000.arneill-py.sacramento.ca.us> Message-Id: <27E6D83D-3CD0-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> a billion /48 prefixes in the global routing table, what do >>> you call this? I call it IPv6 swamp. > >> Kurt Erik Lindqvist wrote: >> It is! No question, but do you want to wait 5+ years? > > You are missing the point. If we had a reasonable expectation that a > scalable flat routing protocol would be available in 5 years, I would > buy the argument. But what do we have today? Zero, not even a > believable > promise. But you think that we will have a billion multihomed networks in five years so we need to go for someting really complicated that we have no experience with? > This is why I used the term "gambling" before. What you are lobbying > for > is to say that it is OK to give away PI and create the IPv6 swamp yes. > because in 5 years we will be able to clean it because by then someone > would have invented The Perfect Routing Protocol (C)(TM). Well, at least we would know what problem we are trying to engineer a solution for. > - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 06:41:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AEf1Qb023055; Mon, 10 Feb 2003 06:41:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AEf0a0023054; Mon, 10 Feb 2003 06:41:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AEevQb023047 for ; Mon, 10 Feb 2003 06:40:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AEf5VL010973 for ; Mon, 10 Feb 2003 06:41:05 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12055 for ; Mon, 10 Feb 2003 07:40:58 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1AEdtlo099244; Mon, 10 Feb 2003 15:39:55 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1AEdlsb246394; Mon, 10 Feb 2003 15:39:48 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA16960 from ; Mon, 10 Feb 2003 15:39:41 +0100 Message-Id: <3E47B97D.52A01C84@hursley.ibm.com> Date: Mon, 10 Feb 2003 15:38:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kurt Erik Lindqvist Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses References: <27E6D83D-3CD0-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurt Erik Lindqvist wrote: > > >>> a billion /48 prefixes in the global routing table, what do > >>> you call this? I call it IPv6 swamp. > > > >> Kurt Erik Lindqvist wrote: > >> It is! No question, but do you want to wait 5+ years? > > > > You are missing the point. If we had a reasonable expectation that a > > scalable flat routing protocol would be available in 5 years, I would > > buy the argument. But what do we have today? Zero, not even a > > believable > > promise. > > But you think that we will have a billion multihomed networks in five > years so we need to go for someting really complicated that we have no > experience with? > > > This is why I used the term "gambling" before. What you are lobbying > > for > > is to say that it is OK to give away PI and create the IPv6 swamp > > yes. I disagree. If our goal (as it should be) is a 10 billion node network (at least) then the risks in allowing even the beginning of a swamp are too great. 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 Mon Feb 10 08:23:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGNGQb024559; Mon, 10 Feb 2003 08:23:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AGNG7U024558; Mon, 10 Feb 2003 08:23:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGNDQb024551 for ; Mon, 10 Feb 2003 08:23:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AGNLVL003204 for ; Mon, 10 Feb 2003 08:23:21 -0800 (PST) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04854 for ; Mon, 10 Feb 2003 08:23:16 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AGNANh009669; Mon, 10 Feb 2003 11:23:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02979; Mon, 10 Feb 2003 11:23:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 11:23:07 -0500 To: dhcwg@ietf.org, , From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph At 11:00 AM 2/6/2003 +0200, Pekka Savola wrote: >On Wed, 5 Feb 2003, Ralph Droms wrote: > > DHCPv6" . The last call will > > conclude on Friday, 2/21. > > > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List option. > > This document is being considered for Proposed Standard as an extension > > to the base DHCPv6 specification, and is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > >A few comments; I haven't looked too deep into DHCPv6 to be able to >comment on those parts, but there are some definite need for revisal in >the doc..: > >2. Requirements > > The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > [...] > >==> I'd put these under Introduction or Terminology sections, no use >having a separate section with a questionable title. > > option-length: Length of the 'options' field in octets; must be a > multiple of 16 Should read "Length of the list of DNS servers in octets; ..." >==> 'options' field has not been defined. Is it the whole option or just >the length of DNS-server address options (I assume so)? If the former, >there must be 32 bits of zero padding. Is it ok that the options aren't >64-bit aligned? It's OK that options are not 64-bit aligned; I don't think the padding is necessary. > The list of domain names in the 'searchstring' MUST be encoded as > specified in section "Representation and use of domain names" of the > DHCPv6 specification [4]. > >==> I didn't bother to check, but I guess this document also defines how >to pad the names to get some desired level of alignment? DHCPv6 doesn't require alignment of the contents of options. >6. Appearance of these options > > The Domain Name Server option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > The Domain Search List option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > >==> I would reword these differently, like: > > The Domain Name Server option MUST NOT appear in other than the following >messages: .... OK. >==> is it ok to server to give only one of these options but not the >other? Yes. >References > >==> split the references OK. > [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. > Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February > 2002. > >==> update this draft version OK. >Author's Address > > Ralph Droms (ed.) > >==> the author is an editor, but the draft does not have acknowledgements >or contributors section. Just remove Editor if nobody else contributed to >the document. Thanks for noticing the oversight. I'll add an acknowledgments seciton. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 08:30:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGUNQb024681; Mon, 10 Feb 2003 08:30:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AGUMFY024680; Mon, 10 Feb 2003 08:30:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGUJQb024673 for ; Mon, 10 Feb 2003 08:30:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AGUSVL005055 for ; Mon, 10 Feb 2003 08:30:28 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18018 for ; Mon, 10 Feb 2003 09:30:22 -0700 (MST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e3.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1AGUL5X046266; Mon, 10 Feb 2003 11:30:21 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1AGRm31071022; Mon, 10 Feb 2003 09:27:49 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h1AGP3600978; Mon, 10 Feb 2003 11:25:04 -0500 Message-Id: <200302101625.h1AGP3600978@rotala.raleigh.ibm.com> To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-Reply-To: Message from mrw@windriver.com of "Fri, 07 Feb 2003 12:58:51 EST." <5.1.0.14.2.20030207125120.030dbba0@mail.windriver.com> Date: Mon, 10 Feb 2003 11:25:03 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is an IPv6 working group last call for comments on submitting the > following document for consideration as a Proposed Standard RFC: My assumption is that the purpose of this document is spelled out in the introduction: While this approach was originally thought to be a good way to allocate IPv6 addresses, subsequent experience and discussion showed that it would be better to leave flexibility in the definition of IPv6 allocation policies to the Internet Address Registries, in order to allow a better balance among the competing requirements. This is consistent with the recommendations made by the IAB and IESG in [RFC3177]. As the above doesn't really have a lot of detail, some more explanation would be good. For example, I still see people occasionally make statements about how IPv6 address allocation will enforce some sort of strict heirarchy (this comes from reading 2374, which this one is obsoleting). Explicitly explaining why that thinking is no longer in vogue would seem useful. Also, this document doesn't say anything about exchanges, whereas 2374 has explicit text. Should this document say anything about this? Are exchanges no longer supported? (I don't think that is the answer, but by not mentioning exchanges, one might draw that conclusion.) As for section 2.0, it seems to just be restating stuff documented in addr-arch. Generally, I think it's better not to repeat stuff from other documents. Also, wording like: The specific format of global unicast address under the 2000::/3 prefix is: might cause some folk to think that the format of addresses under 2000::/3 is somehow different than that for other prefixes. But that isn't the case; the other prefixes generally follow the same format. I don't see how it makes things more clear to single out the 2000::/3 prefix for special discussion on this point. Thus, I think all of Section 2 could be removed. If Section 2.0 is removed, there is nothing in the document that needs to be on standards track. Indeed, given that none of section 2 is new, it all restates stuff on addr-arch, I don't think even this document should go on standards track. Having this document be info, and obsoleting 2473 would work just fine process wise. 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 Mon Feb 10 08:33:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGXXQb024746; Mon, 10 Feb 2003 08:33:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AGXXbu024745; Mon, 10 Feb 2003 08:33:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AGXUQb024738 for ; Mon, 10 Feb 2003 08:33:30 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AGXcVK017465 for ; Mon, 10 Feb 2003 08:33:38 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17143 for ; Mon, 10 Feb 2003 08:33:32 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AGYfhE024240; Mon, 10 Feb 2003 17:34:41 +0100 (CET) Date: Mon, 10 Feb 2003 17:34:40 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com, Michel Py To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3E47B97D.52A01C84@hursley.ibm.com> Message-Id: <8D4649C5-3D15-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I disagree. If our goal (as it should be) is a 10 billion node > network (at least) then the risks in allowing even the beginning > of a swamp are too great. I don't mind us looking at a 10 billion node solution. But I am fairly skeptical that any of the proposals we have today will scale to that though. so starting out with anything should be a good idea.. Otherwise noone will start to use IPv6 and we can discuss theory for ages. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 09:24:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AHOiQb025289; Mon, 10 Feb 2003 09:24:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AHOhTa025288; Mon, 10 Feb 2003 09:24:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AHOeQb025278 for ; Mon, 10 Feb 2003 09:24:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AHOmVL020507 for ; Mon, 10 Feb 2003 09:24:48 -0800 (PST) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27243 for ; Mon, 10 Feb 2003 10:24:43 -0700 (MST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AHOcNh015648; Mon, 10 Feb 2003 12:24:38 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08035; Mon, 10 Feb 2003 12:24:37 -0500 (EST) Message-Id: <4.3.2.7.2.20030210122210.00b665a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 12:24:34 -0500 To: "'dhcwg@ietf.org'" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: [dhcwg] Comments to draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1254192C94D3D411B8060008C7E6AEEBF9DF19@esealnt408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Thanks for the feedback...I've responded in line. - Ralph At 08:58 AM 2/7/2003 +0100, EAB wrote: >In chapter 6. Appearance of these options > >'The Domain Name Server option MUST appear only in the following messages: >Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, >Reply.' > >Confirm message should be removed becaue it is not valid anymore. > >This is even valid for 'Domain Search List' option. Yes. >In References number 4, > >The draft should be update with the RFC number when you know it (for >"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"). OK. >// Tony >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 09:29:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AHTlQb025356; Mon, 10 Feb 2003 09:29:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AHTl4a025355; Mon, 10 Feb 2003 09:29:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AHTiQb025345 for ; Mon, 10 Feb 2003 09:29:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AHTqVL022011 for ; Mon, 10 Feb 2003 09:29:52 -0800 (PST) Received: from bunker.cc.tut.fi (bunker.cc.tut.fi [130.230.1.93]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00658 for ; Mon, 10 Feb 2003 10:29:46 -0700 (MST) Received: from kiuru.cs.tut.fi (daemon@kiuru.cs.tut.fi [130.230.4.18]) by bunker.cc.tut.fi (8.12.5/8.12.5) with ESMTP id h1AHTiNM020772; Mon, 10 Feb 2003 19:29:44 +0200 Received: (from hessu@localhost) by kiuru.cs.tut.fi (8.11.6+Sun/8.8.4) id h1AHTi802231; Mon, 10 Feb 2003 19:29:44 +0200 (EET) X-Authentication-Warning: kiuru.cs.tut.fi: hessu set sender to hessu@cs.tut.fi using -f To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <5.1.0.14.2.20030207125120.030dbba0@mail.windriver.com> From: Heikki Vatiainen Date: 10 Feb 2003 19:29:43 +0200 In-Reply-To: <5.1.0.14.2.20030207125120.030dbba0@mail.windriver.com> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman writes: > This document will replace RFC2374 "An IPv6 Aggregatable Global Unicast > Address Format", which is already a Proposed Standard RFC. RFC2374 will > become historic. If RFC 2374 will become historic, should draft-ietf-ipngwg-addr-arch-v3-11.txt be revised a bit so that it no longer refers to RFC 2374? Or is it already too late? -- Heikki Vatiainen * hessu@cs.tut.fi Tampere University of Technology * Tampere, Finland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 10:33:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AIX1Qb026870; Mon, 10 Feb 2003 10:33:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AIX1Pb026869; Mon, 10 Feb 2003 10:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AIWwQb026862 for ; Mon, 10 Feb 2003 10:32:58 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AIX6VL015594 for ; Mon, 10 Feb 2003 10:33:07 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20482 for ; Mon, 10 Feb 2003 10:33:01 -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 KAA19545 for ; Mon, 10 Feb 2003 10:33:01 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1AIX0c01364 for ; Mon, 10 Feb 2003 10:33:00 -0800 X-mProtect: <200302101833> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfNcR00; Mon, 10 Feb 2003 10:32:57 PST Message-ID: <3E47F0D0.5070802@iprg.nokia.com> Date: Mon, 10 Feb 2003 10:34:56 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Roy et al, I wonder if the setting of the "L" bit in Prefix Information options also bears some mention in this section. RFC 2461, section 4.6.2 says: "When (the L bit is) not set, the advertisment makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link." Does this mean that prefix information options with the L bit not set can be used to auto-configure off-link global or site-local addresses? Thanks, Fred Templin ftemplin@iprg.nokia.com Roy Brabson wrote: >>Not knowing the background of all readers of the doc, it might be good > > to > >>put your explicit warning in the text: >> >> An IPv6 node that does not include an implementation of DHCP will be >> unable to obtain any IPv6 addresses aside from link-local addresses >> when it is connected to a link over which it receives a router >> advertisement with the 'M' flag (Managed address configuration) set >> and which contains no prefixes advertised for Stateless Address >> Autoconfiguration (see section 4.5.2). In this situation, the IPv6 >> Node will be unable to communicate with other off-link nodes. > > > This isn't strictly true - a node may use manually configured global or > site-local IPv6 addresses and still be able to communicate with off-link > nodes. Maybe the first sentence should be updated to indicate the node > will not be able to dynamically obtain any IPv6 addresses, as an IPv6 may > be statically assigned to a node, and the last sentence to indicate a node > will require manual configuration in the absence of DHCP support when > Stateless Address Autoconfiguration is not being used? Something like: > > An IPv6 node that does not include an implementation of DHCP will be > unable to dynamically obtain any IPv6 addresses aside from > link-local addresses when it is connected to a link over which it > receives a router advertisement with the 'M' flag (Managed address > configuration) set and which contains no prefixes advertised for > Stateless Address Autoconfiguration (see section 4.5.2). In this > situation, the IPv6 Node will be unable to communicate with other > off-link nodes unless a global or site-local IPv6 address is > manually configured. > > Roy > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mon Feb 10 10:46:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AIkGQb027070; Mon, 10 Feb 2003 10:46:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1AIkF46027069; Mon, 10 Feb 2003 10:46:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1AIkCQb027062 for ; Mon, 10 Feb 2003 10:46:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1AIkKVL020041 for ; Mon, 10 Feb 2003 10:46:20 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15235 for ; Mon, 10 Feb 2003 11:46:14 -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 h1AIjUd06705; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1AIjUx03167; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Feb 2003 12:45:29 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 10 Feb 2003 12:43:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D134.5C6074C8" 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_01C2D134.5C6074C8 Content-Type: text/plain; charset="ISO-8859-1" Ralph: All of the previous comments should be incorporated. But, in addition: Section 4 and 5 state that a "Server sends ... option to the DHCP client". However, the list of messages in which these options may appear includes client generated messages (Solicit, Request, Renew, Rebind, Information-Request). I believe that client generated messages can request these option codes in an ORO option, but should they include these options? There may be little harm in allowing them? Though it is difficult to see how they could appear in a Solicit even in that case. In section 7, for: Because the Domain Search List option may be used to spoof DNS name resolution in a way that cannot be detected by DNS security mechanisms like DNSSEC [5], DHCP clients and servers MUST use authenticated DHCP when a Domain Search List option is included in a DHCP message. Might it be better to instead state that a client MUST NOT install the Domain Search List unless the message was authenticated? This is cleaner as to what it requires a client and server to do. It is difficult for a client to know in advance whether a server will supply the option? The same might be true of the Domain Name Server option?? Otherwise, the draft looks fine and I would like to see it advanced. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 10, 2003 11:23 AM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph ------_=_NextPart_001_01C2D134.5C6074C8 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Ralph:

All of the previous comments should be incorporated. But, in addition:

Section 4 and 5 state that a "Server sends ... option to the DHCP client".
However, the list of messages in which these options may appear includes
client generated messages (Solicit, Request, Renew, Rebind,
Information-Request).

I believe that client generated messages can request these option codes
in an ORO option, but should they include these options? There may be
little harm in allowing them? Though it is difficult to see how they
could appear in a Solicit even in that case.

In section 7, for:

   Because the Domain Search List option may be used to spoof DNS name
   resolution in a way that cannot be detected by DNS security
   mechanisms like DNSSEC [5], DHCP clients and servers MUST use
   authenticated DHCP when a Domain Search List option is included in a
   DHCP message.

Might it be better to instead state that a client MUST NOT install the Domain
Search List unless the message was authenticated? This is cleaner as to what
it requires a client and server to do. It is difficult for a client to know
in advance whether a server will supply the option?

The same might be true of the Domain Name Server option??

Otherwise, the draft looks fine and I would like to see it advanced.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 10, 2003 11:23 AM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Pekka,

Thanks for the review and feedback; my comments are in line...

And - for other members of the dhc, dnsext and ipv6 WGS: please
respond to this last call notice with comments or an explicit
ack to indicate you accept the draft as published.  Thanks...

- Ralph

------_=_NextPart_001_01C2D134.5C6074C8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 10 13:24:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ALOTQb027968; Mon, 10 Feb 2003 13:24:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1ALOT6V027967; Mon, 10 Feb 2003 13:24:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ALOQQb027960 for ; Mon, 10 Feb 2003 13:24:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1ALOYVL010868 for ; Mon, 10 Feb 2003 13:24:34 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29957 for ; Mon, 10 Feb 2003 13:24:29 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 10 Feb 2003 13:24:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9DA@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcLRElizvzrCMqZeQriVnYW6GdNjBQANNcGA From: "Michel Py" To: "Brian Carpenter" , "Kurt Erik Lindqvist" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1ALOQQb027961 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian / Kurtis, >>> Michel Py wrote: >>> This is why I used the term "gambling" before. What you are >>> lobbying for is to say that it is OK to give away PI and >>> create the IPv6 swamp >> Kurt Erik Lindqvist wrote: >> yes. > Brian E Carpenter wrote: > I disagree. If our goal (as it should be) is a 10 billion > node network (at least) then the risks in allowing even the > beginning of a swamp are too great. I could not agree more with Brian. Something between 1+ billion sites, 10+ billion nodes is the minimum target. Kurtis, IPv6 is *not* IPv4 with more bits. If we wanted to do this, we would have made it 64 bits, say "everything's the same except the address is longer" and we would be done by now. This WG used to be called "IPNG", for "Next Generation". This is what we are talking about here, a new generation, not IPv4 on steroids. 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 10 19:48:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B3mqQb029367; Mon, 10 Feb 2003 19:48:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B3mqq7029366; Mon, 10 Feb 2003 19:48:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B3mmQb029355 for ; Mon, 10 Feb 2003 19:48:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B3mvVL025438 for ; Mon, 10 Feb 2003 19:48:57 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03894 for ; Mon, 10 Feb 2003 19:48:51 -0800 (PST) Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Mon, 10 Feb 2003 19:48:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BDE@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLRIhpbS4jzs+1yQe68TrKFpF5MBwAUFcqA From: "Michel Py" To: "Thomas Narten" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1B3mnQb029356 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas / Bob / Heikki, > Thomas Narten wrote: > [the introduction] > As the above doesn't really have a lot of detail, some more > explanation would be good. Mumble. I have not said anything before not to delay the process, but since it appears we're not going to have a no-brainer anyway, indeed some more explanation would be good. > For example, I still see people occasionally make statements > about how IPv6 address allocation will enforce some sort of > strict heirarchy (this comes from reading 2374, which this > one is obsoleting). Explicitly explaining why that thinking > is no longer in vogue would seem useful. As detailed below, a distinction must be made between the TLA/SLA situation on one side and the SLA on another. > If Section 2.0 is removed, there is nothing in the document that > needs to be on standards track. I strongly disagree on this point and I think there is: some text and a reference to RFC3177, and there's nothing in addr-arch-v3-11.txt. Rationale: We moved three hard boundaries from architecture to policy, the TLA, NLA and SLA. It was clear that the multi-tiered structure of service providers was a matter of allocation and not of architecture, so the TLAs became LIRs, the way they allocate space to lower tiers is none of the IETF's business and all the RIR's. This reasoning is not valid for the SLA boundary though, because although we removed the notion, the block of addresses assigned to an organization will still define the site boundary in most situations. The site boundary has deep consequences on architecture and scope. Indeed, TLAs and SLAs are gone and this is the RIR's business that we don't want to deal with. However, while the SLA is gone, the site boundary remains and this still is our business by the RIR's reading: > [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html] > 5.4. Assignment > LIRs must make IPv6 assignments in accordance with the > following provisions. > 5.4.1. Assignment address space size Assignments are to be made in > accordance with the existing guidelines [RFC3177, RIRs-on-48], > which are summarized here as: > /48 in the general case, except for very large subscribers > /64 when it is known that one and only one subnet is needed by design > /128 when it is absolutely known that one and only one device is > connecting. In short: the bottom line is that the site boundary is now defined by RFC3177, which is what the RIRs call a semi-hard boundary. Given the intricate relations with architecture and scope, I don't see how a reference to it could be left out of the standards track. > Indeed, given that none of section 2 is new, it all restates > stuff on addr-arch, I don't think even this document should go > on standards track. Having this document be info, and obsoleting > 2473 would work just fine process wise. > Heikki Vatiainen wrote: > If RFC 2374 will become historic, should draft-ietf-ipngwg-addr- > arch-v3-11.txt be revised a bit so that it no longer refers to > RFC 2374? Or is it already too late? On paper, it's not a bad idea, but we would need to recall addr-arch to do that, go over last call again. We might have to revisit the /64 hard boundary, the "u" bit and the site-local thing again (for the, what? 6th time?) and possibly have to deal with more appeals. It is urgent to obsolete 2374. Thomas, I can't argue with any of your other points, but you might want to include the need to wrap this up soon in the equation. I have not contributed what is in this message before because I did not want to delay the process, and that stuff still can wait, IMHO. For the sake of having RFCs reasonably in sync with reality, can't we ship two documents on the standards track now and obsolete both of them in the next iteration of addr-arch that would be a single doc? The architecture will continue to evolve, but we need to set a milestone from time to time. 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 10 21:04:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B549Qb029520; Mon, 10 Feb 2003 21:04:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B548SE029519; Mon, 10 Feb 2003 21:04:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B544Qb029511 for ; Mon, 10 Feb 2003 21:04:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B54DVL007777 for ; Mon, 10 Feb 2003 21:04:13 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03446 for ; Mon, 10 Feb 2003 21:04:07 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h1B53vP54529; Tue, 11 Feb 2003 14:03:57 +0900 (JST) Date: Tue, 11 Feb 2003 14:03:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 10 Feb 2003 11:23:07 -0500, >>>>> Ralph Droms said: > And - for other members of the dhc, dnsext and ipv6 WGS: please > respond to this last call notice with comments or an explicit > ack to indicate you accept the draft as published. Thanks... I'm okay to publish the draft. I've reviewed it, and implemented the Domain Name Server option. The specification is useful and important, and (at least regarding the part I implemented) working well. 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 11 00:24:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B8OPQb029820; Tue, 11 Feb 2003 00:24:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B8OPDg029819; Tue, 11 Feb 2003 00:24:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B8OMQb029812 for ; Tue, 11 Feb 2003 00:24:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B8OUVK003773 for ; Tue, 11 Feb 2003 00:24:30 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19226 for ; Tue, 11 Feb 2003 01:24:20 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1B8PQhE024666; Tue, 11 Feb 2003 09:25:28 +0100 (CET) Date: Tue, 11 Feb 2003 09:25:24 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Brian Carpenter" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B9DA@server2000.arneill-py.sacramento.ca.us> Message-Id: <5E32DF8C-3D9A-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>> Michel Py wrote: >>>> This is why I used the term "gambling" before. What you are >>>> lobbying for is to say that it is OK to give away PI and >>>> create the IPv6 swamp > >>> Kurt Erik Lindqvist wrote: >>> yes. > >> Brian E Carpenter wrote: >> I disagree. If our goal (as it should be) is a 10 billion >> node network (at least) then the risks in allowing even the >> beginning of a swamp are too great. > > I could not agree more with Brian. Something between 1+ billion sites, > 10+ billion nodes is the minimum target. > > Kurtis, IPv6 is *not* IPv4 with more bits. If we wanted to do this, we > would have made it 64 bits, say "everything's the same except the > address is longer" and we would be done by now. Exactly!!! IPv6 is IPv4 with a longer address. Nothing more, nothing less. I have been arguing this for quite some time. So the problem is that IPv4 lacks three (or two depending on how you look at it) things 1) Address space shortage 2a) No scalable PI solution 2b) No scalable IDR solution IPv6 addresses 1. We need to find a solution to 2a and 2b. Now, we can either patch IPv6 in one way or the other, or we can start with a clear plate and look at things to see what we can do. I would vote for the second option, otherwise we might as well go with IPv6 swamp, and see what happens. I said it before and I will say it again, without a solution to 2a, no enterprises will go to IPv6, with no enterprises on IPv6 there are no revenues for the ISPs in IPv6, with no revenue from IPv6 the ISPs will not go to IPv6. Just because I can reach a webpage over IPv6 doesn't make the web-page more interesting. If it isn't more interesting I can't charge extra for it. Going to IPv6 will cost the ISPs. Sorry. It doesn't work out. We need to progress on multi6 if this is to take off. I am starting to lean towards the fact that progress in multi6 will require us to look at more drastic measures than patching what we have now. > This WG used to be called "IPNG", for "Next Generation". This is what > we > are talking about here, a new generation, not IPv4 on steroids. > Why do you think IPv6 on steroids will be any better? - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 00:35:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B8Z2Qb029932; Tue, 11 Feb 2003 00:35:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B8Z1bd029931; Tue, 11 Feb 2003 00:35:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B8YwQb029924 for ; Tue, 11 Feb 2003 00:34:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B8Z7VK005401 for ; Tue, 11 Feb 2003 00:35:07 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22824 for ; Tue, 11 Feb 2003 01:34:58 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id DAA01912; Tue, 11 Feb 2003 03:34:53 -0500 (EST) Date: Tue, 11 Feb 2003 03:34:53 -0500 (EST) From: Dan Lanciani Message-Id: <200302110834.DAA01912@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: |Dan Lanciani wrote: |... |> |I wasn't around then, but from what I have been told and read I think |> |everyone was very aware of the scaling issues. But decided to put them |> |forward and buy time. |> |> Well, I was around and I don't recall any major concern. | |This is hard to reconcile with some of the words in RFC 1380, |or what I remember when I first arrived in late 1992. IMHO, by the time 1380 was published in 1992, RFCs were not quite the reflection of community feeling that they had once been. RFC1380 was an attempt to highlight the problem and encourage the concern as much as it was an expression of that concern. Note that while 1380 does brief lip service to other possible solutions (including a distributed one!), it quickly concludes without proof that aggregation must be part of any long-term solution. At least that's the most obvious reading of a sentence that isn't quite English... |My recollection |is of a consensus to buy time with CIDR. There was a consensus to use provider-based hierarchical allocation as a temporary fix for a projected problem. Unfortunately, there was some confusion about how much time we were trying to buy and exactly what we were buying that time for. Initially the plan was presented as just that: hierarchical *allocation* by providers to end users. The addresses so allocated were to be portable and were to belong to the end user. The theory was that this would slow routing table growth, but would ultimately put us right back where we started once enough people changed providers and took their addresses with them. This scheme was perfectly consistent with the notion of "buying time" and it was not going to be a serious burden for end users. Very soon the "allocations" from providers turned into loans (or, at the low end, rentals). It was quickly pointed out that the original notion of letting users take their addresses with them "didn't scale". Suddenly we weren't just buying a little time, we needed to buy indefinite time until some new routing mechanism could be implemented. But since provider control of addresses worked out so well (at least for everyone but new end users) we never saw much effort go into developing that new routing mechanism. Eventually it turned out that what had really been meant by "buy time" was to put off the problem until a new next generation protocol suite could be built. There had never been any intention to return to portable v4 addresses. At least not in retrospect. Now here we are a decade later deploying the next generation of IP and we just need to "buy some time" with provider-based hierarchical address loans. What have we done with all the time we already bought? We didn't do anything to restore portable v4 address allocations. We have a new protocol suite, but it suffers from exactly the same limitation in this respect as v4. What will we do with more time? Some people are quick to point out that we don't have a clue how to solve the problem and that we don't even know how we should be approaching it. If this is true then we might as well be honest and admit that we aren't just "buying time" anymore: IPv6 really is just IPv4 with more address bits. |(Just as PA addressing in IPv6 |buys time; this was in fact strongly debated during the formative |stage of IPng in 1993/94.) Yes, it was strongly debated. Given how long it has taken for v6 to go anywhere, the arguments that there just wasn't time to do anything better initially look less than convincing. In retrospect. I would like to know specifically for what we are buying time with PA addressing in v6, and just how much time we are trying to buy. Absent a visible plan it seems that we will merely repeat the v4 scenario. We will buy time with PA addressing until there is no longer any possibility of getting rid of it. Contrary to the popular quip, it is not easier to go from aggregated to non- aggregated than the reverse--especially if the transition requires any change in the deployed code. |> We were aware |> that there might ultimately be a problem but we were much more open-minded |> about solutions relying both on faster hardware and on new protocols. I |> think that's why some (a lot?) of us were more than a little annoyed at |> being sandbagged by the "CIDR" two-step. What was supposed to be a temporary |> fix quickly evolved into the effective extinction of new portable addresses. |> Since then, hierarchical allocation has become so ingrained that some people |> have trouble even conceptualizing other solutions. | |It's true that RFC 1380 assumed hierarchical allocation. But it also |clearly expressed the distinction between interim solutions (specifically |CIDR) and the long term. It made a distinction between the solutions and then asserted without evidence that any long-term solution had to involve aggregation. By strange coincidence that was the short-term solution as well. I'm sure we could argue the exact semantics of "aggregation" at great length, and certainly in the most abstract sense of summarization it could mean simply that you have to be able to start from *something* and eventually figure out how to route a packet. For such a definition of aggregation the claim that aggregation is necessary is a truism devoid of substance, so I doubt that that is what was intended. |What I think it missed was the whole topic |of identifier/locator separation. That seems to be what we (for |some definition of "we") need to focus on now. I've been trying to focus attention on portable identifiers (which are really just a thinly disguised form of source routing) for years. There seem to be several issues that keep getting in the way: -It is highly unlikely that any solution along the lines of a separate identifier is going to be totally without cost. If we accept the view that any cost is too great then clearly portable identifiers are DOA regardless of the details of the proposal. So I again suggest that we try to reach consensus on how much (if anything) it is worth to us to provide end users with some sort of identifier that is independent of the locator. -It has been suggested that we already depend strongly on being able to infer topology hints from identifiers, even at high levels (i.e., in applications). This is of course anathema to the very goal of making an identifier independent of the locator. Clearly it would be possible to make both the identifier and the locator available to applications, but again this is not going to happen without cost. We should decide whether we really need this and how much we are willing to pay for it. -There seems to be some sentiment that any solution to the portable identifier problem must also solve all other related problems and do so optimally--right away. I think that this is completely backwards. Even a partial solution now that puts in the hooks for further development is better than nothing. As it stands, there is nothing in v6 that makes it more amenable to a separation of identifier and locator than is v4. The only advantage we have (if indeed we still have it) is early access. If we buy time for v6 deployment with PA we will again be in the position of having to wait for another new next generation protocol to solve the problem. |I don't think most people whose BGP tables were exploding felt in the |least sandbagged by BGP4. Of course not; by and large they were the ones doing the sandbagging. Aggregation offers many benefits to providers (increased life for cheaper hardware and address rental revenues being chief among them) at the expense of end users. Sure, there were some end users taking full BGP feeds and they may have been happy to put off a router upgrade. (There were also plenty of users who already had or could quickly get all the portable address space they thought they would need. The transition was of little concern to most of them, though you can bet they won't give up that space now for PA v6 addresses.) But I don't think there is any serious debate about where most of the benefit accrued. 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 11 01:20:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B9K5Qb000364; Tue, 11 Feb 2003 01:20:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B9K47N000361; Tue, 11 Feb 2003 01:20:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B9JxQb000354 for ; Tue, 11 Feb 2003 01:19:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B9K7VL017845 for ; Tue, 11 Feb 2003 01:20:08 -0800 (PST) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15861 for ; Tue, 11 Feb 2003 02:20:01 -0700 (MST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B9Ixn11951; Tue, 11 Feb 2003 16:19:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B9IOb19962; Tue, 11 Feb 2003 16:18:25 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 16:18:24 +0700 Message-ID: <19960.1044955104@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 10 Feb 2003 11:23:07 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> | And - for other members of the dhc, dnsext and ipv6 WGS: please | respond to this last call notice with comments or an explicit | ack to indicate you accept the draft as published. Thanks... With the various changes (mostly fairly minor) that have been suggested, it looks Ok to me. 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 11 01:43:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B9hpQb000514; Tue, 11 Feb 2003 01:43:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1B9ho6p000513; Tue, 11 Feb 2003 01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1B9hlQb000506 for ; Tue, 11 Feb 2003 01:43:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1B9htVK015000 for ; Tue, 11 Feb 2003 01:43:55 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13387 for ; Tue, 11 Feb 2003 01:43:48 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1B9h689038100; Tue, 11 Feb 2003 10:43:11 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1B9h3vh119090; Tue, 11 Feb 2003 10:43:04 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26780 from ; Tue, 11 Feb 2003 10:43:01 +0100 Message-Id: <3E48C575.5F43A6C6@hursley.ibm.com> Date: Tue, 11 Feb 2003 10:42:13 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <963621801C6D3E4A9CF454A1972AE8F54BDE@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 I agree with Michel. Although Thomas is logically correct, I think that including section 2.0 and putting this on standards track is a necessary signal to ensure that TLAs are really understood to be dead. I also think the explicit reference to 2000::/3 is useful. It's the only space currently being allocated. Brian Michel Py wrote: > > Thomas / Bob / Heikki, > > > Thomas Narten wrote: > > [the introduction] > > As the above doesn't really have a lot of detail, some more > > explanation would be good. > > Mumble. I have not said anything before not to delay the process, but > since it appears we're not going to have a no-brainer anyway, indeed > some more explanation would be good. > > > For example, I still see people occasionally make statements > > about how IPv6 address allocation will enforce some sort of > > strict heirarchy (this comes from reading 2374, which this > > one is obsoleting). Explicitly explaining why that thinking > > is no longer in vogue would seem useful. > > As detailed below, a distinction must be made between the TLA/SLA > situation on one side and the SLA on another. > > > If Section 2.0 is removed, there is nothing in the document that > > needs to be on standards track. > > I strongly disagree on this point and I think there is: some text and a > reference to RFC3177, and there's nothing in addr-arch-v3-11.txt. > > Rationale: We moved three hard boundaries from architecture to policy, > the TLA, NLA and SLA. It was clear that the multi-tiered structure of > service providers was a matter of allocation and not of architecture, so > the TLAs became LIRs, the way they allocate space to lower tiers is none > of the IETF's business and all the RIR's. > > This reasoning is not valid for the SLA boundary though, because > although we removed the notion, the block of addresses assigned to an > organization will still define the site boundary in most situations. The > site boundary has deep consequences on architecture and scope. > > Indeed, TLAs and SLAs are gone and this is the RIR's business that we > don't want to deal with. However, while the SLA is gone, the site > boundary remains and this still is our business by the RIR's reading: > > > [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html] > > 5.4. Assignment > > LIRs must make IPv6 assignments in accordance with the > > following provisions. > > 5.4.1. Assignment address space size Assignments are to be made in > > accordance with the existing guidelines [RFC3177, RIRs-on-48], > > which are summarized here as: > > /48 in the general case, except for very large subscribers > > /64 when it is known that one and only one subnet is needed by design > > /128 when it is absolutely known that one and only one device is > > connecting. > > In short: the bottom line is that the site boundary is now defined by > RFC3177, which is what the RIRs call a semi-hard boundary. Given the > intricate relations with architecture and scope, I don't see how a > reference to it could be left out of the standards track. > > > Indeed, given that none of section 2 is new, it all restates > > stuff on addr-arch, I don't think even this document should go > > on standards track. Having this document be info, and obsoleting > > 2473 would work just fine process wise. > > > Heikki Vatiainen wrote: > > If RFC 2374 will become historic, should draft-ietf-ipngwg-addr- > > arch-v3-11.txt be revised a bit so that it no longer refers to > > RFC 2374? Or is it already too late? > > On paper, it's not a bad idea, but we would need to recall addr-arch to > do that, go over last call again. We might have to revisit the /64 hard > boundary, the "u" bit and the site-local thing again (for the, what? 6th > time?) and possibly have to deal with more appeals. It is urgent to > obsolete 2374. > > Thomas, I can't argue with any of your other points, but you might want > to include the need to wrap this up soon in the equation. I have not > contributed what is in this message before because I did not want to > delay the process, and that stuff still can wait, IMHO. > > For the sake of having RFCs reasonably in sync with reality, can't we > ship two documents on the standards track now and obsolete both of them > in the next iteration of addr-arch that would be a single doc? The > architecture will continue to evolve, but we need to set a milestone > from time to time. > > 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 Tue Feb 11 05:24:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDOWQb002167; Tue, 11 Feb 2003 05:24:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BDOWo4002166; Tue, 11 Feb 2003 05:24:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDOTQb002159 for ; Tue, 11 Feb 2003 05:24:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BDOaVL024153 for ; Tue, 11 Feb 2003 05:24:36 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13506 for ; Tue, 11 Feb 2003 05:24:31 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BDNsKo195892; Tue, 11 Feb 2003 08:23:54 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-41.mts.ibm.com [9.65.229.41]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BDNq9Z158256; Tue, 11 Feb 2003 06:23:53 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1BDLiD08172; Tue, 11 Feb 2003 08:21:44 -0500 Message-Id: <200302111321.h1BDLiD08172@cichlid.adsl.duke.edu> To: Heikki Vatiainen cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-Reply-To: Message from hessu@cs.tut.fi of "10 Feb 2003 19:29:43 +0200." Date: Tue, 11 Feb 2003 08:21:44 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heikki Vatiainen writes: > If RFC 2374 will become historic, should > draft-ietf-ipngwg-addr-arch-v3-11.txt be revised a bit so that it no > longer refers to RFC 2374? Or is it already too late? I don't see the reference to 2374 as being a significant problem. Specifically, part of the IESG feedback on addr-arch was to be clear that the reference to 2374 was one possible example, and not normative or The Definitive Example. The only reference to 2374 in the revised document is: Examples of global unicast addresses that start with binary 000 are the IPv6 address with embedded IPv4 addresses described in section 2.5.5 and the IPv6 address containing encoded NSAP addresses specified in [NSAP]. An example of global addresses starting with a binary value other than 000 (and therefore having a 64-bit interface ID field) can be found in [AGGR]. This is quite different than 2374, which has a much stronger reference. 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 11 05:51:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDpLQb002326; Tue, 11 Feb 2003 05:51:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BDpL9u002325; Tue, 11 Feb 2003 05:51:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDpIQb002318 for ; Tue, 11 Feb 2003 05:51:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BDpPVL028196 for ; Tue, 11 Feb 2003 05:51:25 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25616 for ; Tue, 11 Feb 2003 06:51:20 -0700 (MST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BDpICA026914; Tue, 11 Feb 2003 08:51:18 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-41.mts.ibm.com [9.65.229.41]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BDpG9Z155120; Tue, 11 Feb 2003 06:51:17 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1BDn8208223; Tue, 11 Feb 2003 08:49:08 -0500 Message-Id: <200302111349.h1BDn8208223@cichlid.adsl.duke.edu> To: "Michel Py" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-Reply-To: Message from michel@arneill-py.sacramento.ca.us of "Mon, 10 Feb 2003 19:48:51 PST." <963621801C6D3E4A9CF454A1972AE8F54BDE@server2000.arneill-py.sacramento.ca.us> Date: Tue, 11 Feb 2003 08:49:07 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" writes: > > If Section 2.0 is removed, there is nothing in the document that > > needs to be on standards track. > I strongly disagree on this point and I think there is: some text and a > reference to RFC3177, and there's nothing in addr-arch-v3-11.txt. Background: 3177 is a recommendation and represents current thinking. It is not an architectural statement. The /48 boundary is 100% policy. The RIRs have taken that input, and have largely accepted it. This is reflected in the current IPv6 allocation policies, which have been adopted by APNIC, ARIN and RIPE. E.g., see: http://www.arin.net/policy/ipv6_policy.html. IMO, we should declare victory and stop worrying about this. There is no need to for the IETF to make further statements about the /48 boundary at this time. I would also argue that it is wrong to try to push that boundary into an architecture or standards track document, as there is no technical implication on implementations. (Indeed, rather the opposite -- we take great steps to ensure that no implementation will incorrectly assume such a boundary exists and hard code it into the implementation.) > Rationale: We moved three hard boundaries from architecture to policy, > the TLA, NLA and SLA. It was clear that the multi-tiered structure of > service providers was a matter of allocation and not of architecture, so > the TLAs became LIRs, the way they allocate space to lower tiers is none > of the IETF's business and all the RIR's. > This reasoning is not valid for the SLA boundary though, because > although we removed the notion, the block of addresses assigned to an > organization will still define the site boundary in most situations. The > site boundary has deep consequences on architecture and scope. I disagree. Per above, this is not architecture, it is policy. > Indeed, TLAs and SLAs are gone and this is the RIR's business that we > don't want to deal with. However, while the SLA is gone, the site > boundary remains and this still is our business by the RIR's reading: > > [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html] > > 5.4. Assignment > > LIRs must make IPv6 assignments in accordance with the > > following provisions. > > 5.4.1. Assignment address space size Assignments are to be made in > > accordance with the existing guidelines [RFC3177, RIRs-on-48], > > which are summarized here as: > > /48 in the general case, except for very large subscribers > > /64 when it is known that one and only one subnet is needed by design > > /128 when it is absolutely known that one and only one device is > > connecting. > In short: the bottom line is that the site boundary is now defined by > RFC3177, which is what the RIRs call a semi-hard boundary. Given the > intricate relations with architecture and scope, I don't see how a > reference to it could be left out of the standards track. Per above, this is not part of the architecture. This is policy (and good policy, IMO). I do not think it is appropriate to hard wire this into our specifications. > > Indeed, given that none of section 2 is new, it all restates > > stuff on addr-arch, I don't think even this document should go > > on standards track. Having this document be info, and obsoleting > > 2473 would work just fine process wise. > > Heikki Vatiainen wrote: > > If RFC 2374 will become historic, should draft-ietf-ipngwg-addr- > > arch-v3-11.txt be revised a bit so that it no longer refers to > > RFC 2374? Or is it already too late? > On paper, it's not a bad idea, but we would need to recall addr-arch to > do that, go over last call again. We might have to revisit the /64 hard > boundary, the "u" bit and the site-local thing again (for the, what? 6th > time?) and possibly have to deal with more appeals. It is urgent to > obsolete 2374. Yes. Obsoleting 2374 is (from what I can tell) the point of this document. IMO, putting more into the document than needed to achieve just this is a distraction. > Thomas, I can't argue with any of your other points, but you might want > to include the need to wrap this up soon in the equation. I have not > contributed what is in this message before because I did not want to > delay the process, and that stuff still can wait, IMHO. The above could be read to suggest that this document is so important that no changes are appropriate at this point. I have hard time with that, given that we've needed this document for something like 2+ years, and it has been a mere 10 days since the -00 version appeared. One can get documents done quickly, so long as there is rapid discussion, iteration and convergence. Let me suggest we try this first. There is a time to surpress the urge for changes in a document, but it seems a little early to be there for this one. > For the sake of having RFCs reasonably in sync with reality, can't we > ship two documents on the standards track now and obsolete both of them > in the next iteration of addr-arch that would be a single doc? The > architecture will continue to evolve, but we need to set a milestone > from time to time. I see no need to tie this document with the already approved 2374bis. If a merge is needed, we can do that later. 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 11 05:51:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDpYQb002336; Tue, 11 Feb 2003 05:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BDpY1r002335; Tue, 11 Feb 2003 05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BDpTQb002328 for ; Tue, 11 Feb 2003 05:51:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BDpaVL028215 for ; Tue, 11 Feb 2003 05:51:36 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25688 for ; Tue, 11 Feb 2003 06:51:31 -0700 (MST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BDpTKo270472; Tue, 11 Feb 2003 08:51:29 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-41.mts.ibm.com [9.65.229.41]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BDpN9Z155132; Tue, 11 Feb 2003 06:51:28 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1BDnEp08233; Tue, 11 Feb 2003 08:49:14 -0500 Message-Id: <200302111349.h1BDnEp08233@cichlid.adsl.duke.edu> To: Brian E Carpenter cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-Reply-To: Message from brian@hursley.ibm.com of "Tue, 11 Feb 2003 10:42:13 +0100." <3E48C575.5F43A6C6@hursley.ibm.com> Date: Tue, 11 Feb 2003 08:49:14 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with Michel. Although Thomas is logically correct, > I think that including section 2.0 and putting this on > standards track is a necessary signal to ensure that TLAs > are really understood to be dead. Let me ask a pragmatic question. If this document goes on standards track, how will this document advance up the Standards Track? What will the implementation reports contain and actually test? I don't see immediately anything that is testable. This is one of the reasons I don't see Standards Track is being the right classification. > I also think the explicit reference to 2000::/3 is useful. > It's the only space currently being allocated. I'm not sure what this means. If we want to say only 2000::/3 is currently allocated, that might be fine. But the current document doesn't say that (indeed, it says nothing about what has and has not been allocated). Instead, it talks about formats. And why aren't the words in addr-arch good enough about the 2000::/3 allocation? 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 11 07:03:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BF3oQb002728; Tue, 11 Feb 2003 07:03:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BF3ouD002727; Tue, 11 Feb 2003 07:03:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BF3kQb002720 for ; Tue, 11 Feb 2003 07:03:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BF3sVL011218 for ; Tue, 11 Feb 2003 07:03:54 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13630 for ; Tue, 11 Feb 2003 07:03:48 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1BF3gTQ082130; Tue, 11 Feb 2003 16:03:43 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1BF3gvh008636; Tue, 11 Feb 2003 16:03:42 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21814 from ; Tue, 11 Feb 2003 16:03:38 +0100 Message-Id: <3E491099.941F46C2@hursley.ibm.com> Date: Tue, 11 Feb 2003 16:02:49 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Thomas Narten Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <200302111349.h1BDnEp08233@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > > I agree with Michel. Although Thomas is logically correct, > > I think that including section 2.0 and putting this on > > standards track is a necessary signal to ensure that TLAs > > are really understood to be dead. > > Let me ask a pragmatic question. If this document goes on standards > track, how will this document advance up the Standards Track? What > will the implementation reports contain and actually test? I don't see > immediately anything that is testable. This is one of the reasons I > don't see Standards Track is being the right classification. Good point (but doesn't it also apply to the address architecture to a large extent?). BCP is our usual way out of that. I stick to me feeling that we need a stronger signal than Informational, but I wouldn't go to the wall over it. > > > I also think the explicit reference to 2000::/3 is useful. > > It's the only space currently being allocated. > > I'm not sure what this means. If we want to say only 2000::/3 is > currently allocated, that might be fine. But the current document > doesn't say that (indeed, it says nothing about what has and has not > been allocated). Instead, it talks about formats. And why aren't the > words in addr-arch good enough about the 2000::/3 allocation? They are OK. If we were just writing mathematical theorems, they would be sufficient; as I said you are logically correct. I just think we need to make the point in a short stand-alone document, even if there is some redundancy. 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 Tue Feb 11 07:21:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFLLQb002916; Tue, 11 Feb 2003 07:21:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BFLLgp002915; Tue, 11 Feb 2003 07:21:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFLIQb002908 for ; Tue, 11 Feb 2003 07:21:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BFLQVL014883 for ; Tue, 11 Feb 2003 07:21:26 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12268 for ; Tue, 11 Feb 2003 07:21:17 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1BFL3lo056242 for ; Tue, 11 Feb 2003 16:21:08 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1BFL31J048654 for ; Tue, 11 Feb 2003 16:21:03 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27900 from ; Tue, 11 Feb 2003 16:21:00 +0100 Message-Id: <3E4914AB.8496596B@hursley.ibm.com> Date: Tue, 11 Feb 2003 16:20:11 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <200302111349.h1BDn8208223@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > "Michel Py" writes: > > > > If Section 2.0 is removed, there is nothing in the document that > > > needs to be on standards track. > > > I strongly disagree on this point and I think there is: some text and a > > reference to RFC3177, and there's nothing in addr-arch-v3-11.txt. > > Background: 3177 is a recommendation and represents current > thinking. It is not an architectural statement. The /48 boundary is > 100% policy. The RIRs have taken that input, and have largely accepted > it. This is reflected in the current IPv6 allocation policies, which > have been adopted by APNIC, ARIN and RIPE. E.g., see: > http://www.arin.net/policy/ipv6_policy.html. It's a very light reference to 3177. I think it's useful to make the point that the RIR policy and the IAB/IESG recommendation are consistent. It's a footnote though. > > IMO, we should declare victory and stop worrying about this. There is > no need to for the IETF to make further statements about the /48 > boundary at this time. I would also argue that it is wrong to try to > push that boundary into an architecture or standards track document, > as there is no technical implication on implementations. (Indeed, > rather the opposite -- we take great steps to ensure that no > implementation will incorrectly assume such a boundary exists and hard > code it into the implementation.) Agreed, and the draft doesn't do that. > > > Rationale: We moved three hard boundaries from architecture to policy, > > the TLA, NLA and SLA. It was clear that the multi-tiered structure of > > service providers was a matter of allocation and not of architecture, so > > the TLAs became LIRs, the way they allocate space to lower tiers is none > > of the IETF's business and all the RIR's. > > > This reasoning is not valid for the SLA boundary though, because > > although we removed the notion, the block of addresses assigned to an > > organization will still define the site boundary in most situations. The > > site boundary has deep consequences on architecture and scope. > > I disagree. Per above, this is not architecture, it is policy. I agree with Thomas, but the draft doesn't go there anyway. > > > Indeed, TLAs and SLAs are gone and this is the RIR's business that we > > don't want to deal with. However, while the SLA is gone, the site > > boundary remains and this still is our business by the RIR's reading: > > > > [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html] > > > 5.4. Assignment > > > LIRs must make IPv6 assignments in accordance with the > > > following provisions. > > > 5.4.1. Assignment address space size Assignments are to be made in > > > accordance with the existing guidelines [RFC3177, RIRs-on-48], > > > which are summarized here as: > > > /48 in the general case, except for very large subscribers > > > /64 when it is known that one and only one subnet is needed by design > > > /128 when it is absolutely known that one and only one device is > > > connecting. > > > In short: the bottom line is that the site boundary is now defined by > > RFC3177, which is what the RIRs call a semi-hard boundary. Given the > > intricate relations with architecture and scope, I don't see how a > > reference to it could be left out of the standards track. > > Per above, this is not part of the architecture. This is policy (and > good policy, IMO). I do not think it is appropriate to hard wire this > into our specifications. Correct. If the draft attempted to make a normative referennce to 3177, it would be a blunder. But it doesn't. > > > > Indeed, given that none of section 2 is new, it all restates > > > stuff on addr-arch, I don't think even this document should go > > > on standards track. Having this document be info, and obsoleting > > > 2473 would work just fine process wise. > > > > Heikki Vatiainen wrote: > > > If RFC 2374 will become historic, should draft-ietf-ipngwg-addr- > > > arch-v3-11.txt be revised a bit so that it no longer refers to > > > RFC 2374? Or is it already too late? > > > On paper, it's not a bad idea, but we would need to recall addr-arch to > > do that, go over last call again. We might have to revisit the /64 hard > > boundary, the "u" bit and the site-local thing again (for the, what? 6th > > time?) and possibly have to deal with more appeals. It is urgent to > > obsolete 2374. > > Yes. Obsoleting 2374 is (from what I can tell) the point of this > document. IMO, putting more into the document than needed to achieve > just this is a distraction. I really don't find that the text you are objecting to is a distraction. I think it makes the draft more comprehensible. But it's a judgement call, so I'd like some other people to comment. > > > Thomas, I can't argue with any of your other points, but you might want > > to include the need to wrap this up soon in the equation. I have not > > contributed what is in this message before because I did not want to > > delay the process, and that stuff still can wait, IMHO. > > The above could be read to suggest that this document is so important > that no changes are appropriate at this point. I have hard time with > that, given that we've needed this document for something like 2+ > years, and it has been a mere 10 days since the -00 version appeared. > > One can get documents done quickly, so long as there is rapid > discussion, iteration and convergence. Let me suggest we try this > first. There is a time to surpress the urge for changes in a document, > but it seems a little early to be there for this one. > > > For the sake of having RFCs reasonably in sync with reality, can't we > > ship two documents on the standards track now and obsolete both of them > > in the next iteration of addr-arch that would be a single doc? The > > architecture will continue to evolve, but we need to set a milestone > > from time to time. > > I see no need to tie this document with the already approved > 2374bis. If a merge is needed, we can do that later. I assume you mean 2373bis. I don't see why a merge would be needed. We do need to delete the reference to 2374 in 2373bis, but that's editorial. 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 Tue Feb 11 07:27:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFRCQb002998; Tue, 11 Feb 2003 07:27:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BFRCr1002997; Tue, 11 Feb 2003 07:27:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFR8Qb002990 for ; Tue, 11 Feb 2003 07:27:08 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BFRGVL016124 for ; Tue, 11 Feb 2003 07:27:16 -0800 (PST) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29636 for ; Tue, 11 Feb 2003 07:27:11 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1BFR7Nh002492; Tue, 11 Feb 2003 10:27:08 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21726; Tue, 11 Feb 2003 10:27:07 -0500 (EST) Message-Id: <4.3.2.7.2.20030211102344.03d88c40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 10:27:05 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc, and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 11 07:38:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFc2Qb003182; Tue, 11 Feb 2003 07:38:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BFc2C4003181; Tue, 11 Feb 2003 07:38:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BFbxQb003174 for ; Tue, 11 Feb 2003 07:37:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BFc6VL018416 for ; Tue, 11 Feb 2003 07:38:06 -0800 (PST) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25856 for ; Tue, 11 Feb 2003 08:38:01 -0700 (MST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1BFbwNh003200; Tue, 11 Feb 2003 10:37:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA23101; Tue, 11 Feb 2003 10:37:57 -0500 (EST) Message-Id: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 10:37:56 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (resent with correct Subject:) This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc, and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 11 10:17:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BIHsQb004046; Tue, 11 Feb 2003 10:17:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BIHrBM004045; Tue, 11 Feb 2003 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BIHoQb004038 for ; Tue, 11 Feb 2003 10:17:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BIHwVK010119 for ; Tue, 11 Feb 2003 10:17:58 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23888 for ; Tue, 11 Feb 2003 11:17:48 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1BIHk9c045842 for ; Tue, 11 Feb 2003 13:17:46 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1BIHkNx043567 for ; Tue, 11 Feb 2003 13:17:46 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1BIHjXG043564 for ; Tue, 11 Feb 2003 13:17:46 -0500 (EST) Date: Tue, 11 Feb 2003 13:17:45 -0500 (EST) From: "Alan E. Beard" To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <200302110834.DAA01912@ss10.danlan.com> Message-ID: <20030211114304.D43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, Brian: A bit of historical information and some comments on the current issue included below. AEB On Tue, 11 Feb 2003, Dan Lanciani wrote: > Brian E Carpenter wrote: > > |Dan Lanciani wrote: > |... > |> |I wasn't around then, but from what I have been told and read I think > |> |everyone was very aware of the scaling issues. But decided to put them > |> |forward and buy time. > |> > |> Well, I was around and I don't recall any major concern. > | > |This is hard to reconcile with some of the words in RFC 1380, > |or what I remember when I first arrived in late 1992. > I _was_ around, and I _do_ remember these events. Here is the best of my recollection. About 1992 the community of user-network admininstrators (of which I was then a member) began to show considerable uneasiness about a looming shortage of IPv4 registered address space. Within two years class B address allocations were becoming very scarce, and registered class Bs were becoming increasingly hard to get. In 1996, a company for which I was acting as network administrator _gave_ one of their registered Class B allocations to a local residential community with had been unable to obtain sufficient registered space via the normal applications process! Many networks converted to VLSM, and others began to use PNN space, in an attempt to stave off the inevitable restrictions on growth which the scarcity of registered IPv4 space was expected (not inaccurately) to impose. The later introduction of CIDR and provider-based addressing, as you well know, enabled the vast growth of the "online" services (AOL and entities of that ilk), but at the cost of great operational difficulties for privately-operated networks which needed to expand. Use of PNN and NAT grew explosively. In summary: yes, there was knowledge and concern over the IPv4 address scarcity issues as early as 1992. There were some administrative (as distinguished from technical) managers who chose to play ostrich (you know what that bird exposes when it sticks its head in the sand), but the user technical community was aware of, and alarmed about, the issue. Subsequent experience with provider-based addressing has convinced almost all administrative managers of privately-operated networks, and most technical managers and network administrators, that renumbering is to be avoided at any cost short of summary hanging. Absent the ready availability of provider-independent, globally routable address space, I suspect that most of my clients will continue to require the use of non-globally-routable addressing in their internal networks, with NAT and application-level gateways used where public-network access cannot be avoided. As indicated by the general sentiment in this WG, the conditions described immediately above are, to put it politely, far from desirable. This account puts me in mind of a quote from Mark Twain (Sam Clemens),to wit: "a cat, once he has sat on a hot stove lid, will not do so again; but he'll never sit on a cold one either". The user-network managers are unlikely to change their opinion in the foreseeable future, engineering advice to the contrary notwithstanding. > IMHO, by the time 1380 was published in 1992, RFCs were not quite the > reflection of community feeling that they had once been. RFC1380 was an > attempt to highlight the problem and encourage the concern as much as it was > an expression of that concern. Note that while 1380 does brief lip service to > other possible solutions (including a distributed one!), it quickly concludes > without proof that aggregation must be part of any long-term solution. At > least that's the most obvious reading of a sentence that isn't quite English... > > |My recollection > |is of a consensus to buy time with CIDR. > This accords with my memory: CIDR was seen as a stopgap, to provide, at best, temporary relief until IPNG could be got into service. CIDR and its familiar, aggregation, were considered necessary as distinguished from desirable. Provider-based addressing was seen by most user-network administrators as a definite evil, and there was considerable consternation when the PA model was specified as the default allocation scheme for IPv6. So much for the historical context from the standpoint of end-user-network administrators. We are now (as pointed out at some length by others below) reaping the consequences of a decision to use hierarchical PA as a tool to achive route aggregation: the situation is about as appetizing as attempting to swallow a porcupine wrong-end-to. Based on experience with my clients, I strongly suspect that end-user networks will not embrace IPv6 enthusiastically unless registered, globally routable PI space is readily available. Independent of the technical merits of routing aggregation, PA addressing, with its history of lack of portability and the renumbering overhead, will be seen as a probibitively disruptive for almost all end-user-network administrative managers, and for most technical managers and network administrators. > There was a consensus to use provider-based hierarchical allocation as a > temporary fix for a projected problem. Unfortunately, there was some confusion > about how much time we were trying to buy and exactly what we were buying that > time for. > > Initially the plan was presented as just that: hierarchical *allocation* by > providers to end users. The addresses so allocated were to be portable and > were to belong to the end user. The theory was that this would slow routing > table growth, but would ultimately put us right back where we started once > enough people changed providers and took their addresses with them. This > scheme was perfectly consistent with the notion of "buying time" and it was > not going to be a serious burden for end users. > [...] > Dan Lanciani > ddl@danlan.*com That's my $.02 worth. AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 11:09:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BJ9CQb004498; Tue, 11 Feb 2003 11:09:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BJ9C0n004497; Tue, 11 Feb 2003 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BJ99Qb004490 for ; Tue, 11 Feb 2003 11:09:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BJ9GVK027894 for ; Tue, 11 Feb 2003 11:09:16 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02337 for ; Tue, 11 Feb 2003 11:09:11 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BJ98Ko169056 for ; Tue, 11 Feb 2003 14:09:08 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-198-184.mts.ibm.com [9.65.198.184]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BJ6Z9Z165224; Tue, 11 Feb 2003 12:06:35 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1BJ4PV03961; Tue, 11 Feb 2003 14:04:26 -0500 Message-Id: <200302111904.h1BJ4PV03961@cichlid.adsl.duke.edu> To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-Reply-To: Message from brian@hursley.ibm.com of "Tue, 11 Feb 2003 16:20:11 +0100." <3E4914AB.8496596B@hursley.ibm.com> Date: Tue, 11 Feb 2003 14:04:25 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes. Obsoleting 2374 is (from what I can tell) the point of this > > document. IMO, putting more into the document than needed to achieve > > just this is a distraction. > I really don't find that the text you are objecting to is a distraction. > I think it makes the draft more comprehensible. But it's a judgement > call, so I'd like some other people to comment. Agreed. Trying to make this document a Proposed Standard is what makes me uncomfortable. There is nothing in it that is defining anything new in a standard's sense (at least, AFAIK). If it were informational, this issue would just go away. I guess some are arguing informational is not a strong enough signal, but I don't personally agree with that. Reclassifying a document as historic, and obsoleting it seems pretty clear to me. [side note: the MUST/MAY definitions can now be removed as they are no longer used.] Brian E Carpenter writes: > > Let me ask a pragmatic question. If this document goes on standards > > track, how will this document advance up the Standards Track? What > > will the implementation reports contain and actually test? I don't see > > immediately anything that is testable. This is one of the reasons I > > don't see Standards Track is being the right classification. > Good point (but doesn't it also apply to the address architecture > to a large extent?). BCP is our usual way out of that. Similar reasoning applies to addr arch. I think that making it a BCP might in retrospect also have been an alternative approach. But, that document also has a lot more in it, so it's easier to find stuff in that is clearly implementation related. But there is also pieces where the connection is not immediately obvious... 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 11 11:14:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BJEuQb004738; Tue, 11 Feb 2003 11:14:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1BJEuV9004737; Tue, 11 Feb 2003 11:14:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1BJEqQb004727 for ; Tue, 11 Feb 2003 11:14:53 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1BJF0VK000385 for ; Tue, 11 Feb 2003 11:15:00 -0800 (PST) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28309 for ; Tue, 11 Feb 2003 11:14:55 -0800 (PST) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h1BJDbo5015848; Tue, 11 Feb 2003 14:13:37 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Feb 2003 14:12:59 -0500 Message-ID: <3E494BAB.5080103@nc.rr.com> Date: Tue, 11 Feb 2003 14:14:51 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <200302111904.h1BJ4PV03961@cichlid.adsl.duke.edu> In-Reply-To: <200302111904.h1BJ4PV03961@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that Informational is the correct level. I also don't see anything in the doc that is "new" and needs to be a Standard. Regards, Brian Thomas Narten wrote: >>>Yes. Obsoleting 2374 is (from what I can tell) the point of this >>>document. IMO, putting more into the document than needed to achieve >>>just this is a distraction. > > >>I really don't find that the text you are objecting to is a distraction. >>I think it makes the draft more comprehensible. But it's a judgement >>call, so I'd like some other people to comment. > > > Agreed. > > Trying to make this document a Proposed Standard is what makes me > uncomfortable. There is nothing in it that is defining anything new in > a standard's sense (at least, AFAIK). If it were informational, this > issue would just go away. > > I guess some are arguing informational is not a strong enough signal, > but I don't personally agree with that. Reclassifying a document as > historic, and obsoleting it seems pretty clear to me. > > [side note: the MUST/MAY definitions can now be removed as they are no > longer used.] > > Brian E Carpenter writes: > > >>>Let me ask a pragmatic question. If this document goes on standards >>>track, how will this document advance up the Standards Track? What >>>will the implementation reports contain and actually test? I don't see >>>immediately anything that is testable. This is one of the reasons I >>>don't see Standards Track is being the right classification. > > >>Good point (but doesn't it also apply to the address architecture >>to a large extent?). BCP is our usual way out of that. > > > Similar reasoning applies to addr arch. I think that making it a BCP > might in retrospect also have been an alternative approach. But, that > document also has a lot more in it, so it's easier to find stuff in > that is clearly implementation related. But there is also pieces where > the connection is not immediately obvious... > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 11 21:03:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1C53BQb008315; Tue, 11 Feb 2003 21:03:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1C53BcS008314; Tue, 11 Feb 2003 21:03:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1C537Qb008307 for ; Tue, 11 Feb 2003 21:03:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1C53FVL003567 for ; Tue, 11 Feb 2003 21:03:15 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12852 for ; Tue, 11 Feb 2003 21:03:09 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 492004FF7; Wed, 12 Feb 2003 00:03:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 00:03:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Wed, 12 Feb 2003 00:03:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ECC@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLN0x8VGo9fNJOCQH6oRh5Ju9xNrAEfdo9w From: "Bound, Jim" To: Cc: X-OriginalArrivalTime: 12 Feb 2003 05:03:09.0210 (UTC) FILETIME=[0921EFA0:01C2D254] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1C538Qb008308 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, It should be SHOULD. The M bit means "use" Tasteful. The "O" bit means use Stateful. Two different contexts. I was here when they were put in ND and recall why. One reason is that not everyone believed that just stateless was acceptable and that was vision on those persons part. The reality is that most users will not use stateless but Statefull simply out of habit first of all and second the trust model will not be delegated to routers for IPv6 for some time until users are more comfortable with the stateless model. I also consider not doing a SHOULD for these bits is irresponsible engineering of a standard on our part. If a user wants stateful which is clearly permitted in ND and in the IPv6 architecture they should be able to use it. But reality is that as any product engineer knows when you develop the code first time and see MAYs you usually skip it. But that is just a side issue and logic. The reason is as I said. M/O bit says use stateful. For this to not be a SHOULD is to denigrate a part of the IPv6 architecture and this is simply wrong. Putting words in that if you do this you will hurt yourself tells us it should be a SHOULD. If something can hurt users and this can it can affect interoperability and deployment. I could also argue if the "M" bit is set and nodes don't go to a stateful server because they "cannot" it is another form of DOS. The case where I personally don't believe stateful is valid is for small mobile devices for users like 3GPP, 802.11 hot-spots, military operations, et al. But in those cases. Except in one scenario which I won't get into. Long term I see stateless used more and more, but I don't see Enterprises or any very large entity using stateless for a very long time. But in cases where it might not make sense the market will decide and not set the M bit. But if they set it then that means it's a SHOULD. SHOULD means implement this unless you have a good reason to not implement it. For devices I spoke of above there is good reason to not implement it IMO so don't. Small device only believers and die-hard stateless is the only model should not use this forum to backdoor remove what is part of the IPv6 architecture. I believe if we do that then it must be raised to a higher level and question of Internet Architecture principles based on the base specs for the architecture. The other problem is that stateless brings with it many problems we will have to deal with in deployment till we learn more. The users will see this too and will be conservative and drop back to stateful. This is a very serious issue. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 05:43:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CDhmQb010007; Wed, 12 Feb 2003 05:43:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CDhlNr010006; Wed, 12 Feb 2003 05:43:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CDhiQb009999 for ; Wed, 12 Feb 2003 05:43:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CDhrVK016069 for ; Wed, 12 Feb 2003 05:43:53 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00555 for ; Wed, 12 Feb 2003 05:43:47 -0800 (PST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6ADF41C; Wed, 12 Feb 2003 15:52:03 +0200 (EET) Message-ID: <3E4A4F79.1040304@nomadiclab.com> Date: Wed, 12 Feb 2003 15:43:21 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG Cc: SEND WG Subject: Reason for the explicit link-layer address options in ND? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the behalf of the SEND DT, I'd like to get a clarification to the current ND design from those who were around back when RFC2461 and RFC2462 were written. Specifically, we'd like the know the exact reasons why RFC2461 uses separate source/target link layer address options instead of relying on the actual source link layer addresses used in the link layer frame? Furthermore, why are the actual link layer addresses used in the link layer frame completely ignored, and not checked to match with the options? Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? The reason why I am asking this is that the current situation makes security design tricky. That is, the Secure ND part of SEND (as opposed to Secure RD) is all about creating a secure binding between an IP address and a link layer address. The WG decided to pursue the idea of using public key based AH to secure the NA (and NS) messages. That requires that the hosts learn the public keys of the other hosts on the local link. Basically, there are two know methods for distributing the public keys: Using certificates and relying on a (local) CA, or using Cryptographically Generated Addresses (CGA). Now, for zero-config operation, we would like to use the CGA ideas. Furthermore, there is a possible attack against link local addresses, and that attack can be partially dwarfed if we bind both the link layer address and the public key to the IP address in CGA. Under the current design, the CGA processing at the AH layer becomes very tricky, if we attempt to include the link layer address into the CGA process. --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 12 06:30:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CEUrQb010328; Wed, 12 Feb 2003 06:30:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CEUr2N010327; Wed, 12 Feb 2003 06:30:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CEUnQb010320 for ; Wed, 12 Feb 2003 06:30:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CEUwVK029355 for ; Wed, 12 Feb 2003 06:30:58 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28885 for ; Wed, 12 Feb 2003 06:30:53 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 81E7F902E; Wed, 12 Feb 2003 09:30:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 09:30:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 09:30:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLSnUu7enGrxmChQgmQ6/1J2n4lRwAAmKqA From: "Bound, Jim" To: "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" X-OriginalArrivalTime: 12 Feb 2003 14:30:52.0421 (UTC) FILETIME=[58637350:01C2D2A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CEUoQb010321 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, I can give you one answer and recall the discussion very well in Cambridge MA well at an early interim IPng WG meeting (~1995) and this is where we agreed to solicited node mulitcast archictecture principle, as a note too. For Neighbor Discovery (ND) RFC 2461: IPv4 and OSI too and many other previous implementations of a Internet like network paradigm relied on address resoluton and node discovery at the link layer of the network stack in conjunction with peeking at the link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer, Router Redirects, and ARP-Like funcitons were brought up to be part of the IP layer processing, which is one of the clear advantages of IPv6 IMO that we often don't tout (though steve brings this point out in his masters and other talks). There is an architecture and implementation reason. Architecturally this affords ND to be part of the IP(v6) layer and part of the extensibility of that architecture as required (e.g. new ICMP types, Routing Options, Destination Options). This can be seen from the DNS Discovery deliberation and suggestion to use new ICMP type for finding ones DNS server on a stateless network. It can be seen in Next Header chain. With ARP or ES-IS this was not possible. In those archictectures the address resolution and node discovery are disjoint from the actual "virtual" layer 3 processing. >From implementation perspective it supports the principle of cohesiveness when building the network subsystem. What this means is that the code points for IP processing are now integral to the ND methods and concepts like NUD and prefix assimilation from ND are now part of the IP stack code base. NUD and prefix assimilation (just two examples as a note) are part of ND architecture and support that principle. The "implementors" of IPv6 and SIP (initial predecessor to IPv6 and IPng choice) learned the implementation advantages of ND methods and its place in the IPv6 architecture over implementations they had done for ARP and ES-IS. So it was a win for the Architecture, Implemenation, and combined the best from multiple methods previously done for address resolution, node discovery, and router redirects. The last win was only possible by integrating into the the IP layer. IPv6 Stateless Autoconfiguration RFC 2462. This just adhered to the base packet types of ND and then added the processes. The reason the link layer addresses are options was to permit extensibility for ND and Autoconfig to be extensible to the win list above of which address resolution and node discovery were only part. Another reason is support future models for proxy and passing link-layer addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was to support the use of the Override bit which can be part of address resolution and node discovery during first phase when link-layer addresses are not shared or to inform implementation this is temporary do not update your NUD cache. The reason for not peeking at the link layer in ND or Autoconfig is separation of function within the IP architecture. There is no requirement for this in previous models like ARP and ES-IS. If you look at public domain network kernel implementations of BSD or Linux derivations you will see the Ether (*) routines exist and for multiple adapter types. Also you might want to look at the various IPv6 over Foo specs that deal with how to deal with different link layer types. The check with the link-layer is a link layer function not an IP layer issue. In fact it is done on most implementations before the packet comes off the interrupt queue to hit the IP layer. Lastly if there is a bug here it would be caught in the NUD state machine and time out. Regards, /jim >-----Original Message----- >From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >Sent: Wednesday, February 12, 2003 8:43 AM >To: IPV6 WG >Cc: SEND WG >Subject: Reason for the explicit link-layer address options in ND? > > >On the behalf of the SEND DT, I'd like to get >a clarification to the current ND design from >those who were around back when RFC2461 and >RFC2462 were written. > >Specifically, we'd like the know the exact >reasons why RFC2461 uses separate source/target link >layer address options instead of relying on the >actual source link layer addresses used in the >link layer frame? Furthermore, why are the actual >link layer addresses used in the link layer frame >completely ignored, and not checked to match with >the options? > >Is this just a layering question, an attempt to >avoid layer violations? Or were there behind >other goals, like allowing proxy ND? > >The reason why I am asking this is that the current >situation makes security design tricky. That is, >the Secure ND part of SEND (as opposed to Secure RD) >is all about creating a secure binding between an IP >address and a link layer address. > >The WG decided to pursue the idea of using public >key based AH to secure the NA (and NS) messages. >That requires that the hosts learn the public keys >of the other hosts on the local link. Basically, >there are two know methods for distributing the >public keys: Using certificates and relying on >a (local) CA, or using Cryptographically Generated >Addresses (CGA). > >Now, for zero-config operation, we would like to >use the CGA ideas. Furthermore, there is a possible >attack against link local addresses, and that attack >can be partially dwarfed if we bind both the link >layer address and the public key to the IP address >in CGA. > >Under the current design, the CGA processing at the >AH layer becomes very tricky, if we attempt to include >the link layer address into the CGA process. > >--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 12 06:35:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CEZeQb010454; Wed, 12 Feb 2003 06:35:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CEZet5010453; Wed, 12 Feb 2003 06:35:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CEZbQb010446 for ; Wed, 12 Feb 2003 06:35:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CEZjVK000672 for ; Wed, 12 Feb 2003 06:35:45 -0800 (PST) Received: from srexchimc2.eng.emc.com (srexchimc2.lss.emc.com [168.159.40.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02365 for ; Wed, 12 Feb 2003 06:35:40 -0800 (PST) Received: by srexchimc2.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 09:35:40 -0500 Message-ID: <33CE6457C7003A478381BCD0B584DEC502740E40@srmoon.eng.emc.com> From: "sasson, shuki" To: ipng@sunroof.eng.sun.com Subject: Testing tool for out IPv6 stack. Date: Wed, 12 Feb 2003 09:35:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CEZbQb010447 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, we are developing an IPv6 stack for our products. I wander if you can recommend us for a good testing tool for the IPv6 stack. Thanks, Shuki Sasson Principal Engineer, Network Storage Group EMC² where information lives Phone: 508 305 8515 FaxNo: 508 435 8901 Pager: 877 919 0794 Email: sasson_shuki@emc.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 12 07:00:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CF0CQb010670; Wed, 12 Feb 2003 07:00:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CF0CwD010669; Wed, 12 Feb 2003 07:00:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CF09Qb010662 for ; Wed, 12 Feb 2003 07:00:09 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CF0IVK005836 for ; Wed, 12 Feb 2003 07:00:18 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19461 for ; Wed, 12 Feb 2003 07:00:12 -0800 (PST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1CF07h01018; Wed, 12 Feb 2003 16:00:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1CEwIof095565; Wed, 12 Feb 2003 15:58:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? In-reply-to: Your message of Wed, 12 Feb 2003 15:43:21 +0200. <3E4A4F79.1040304@nomadiclab.com> Date: Wed, 12 Feb 2003 15:58:18 +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: Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? => both reasons. In the same kind of design ideas, it is forbidden to mix unicast and multicast between layers, i.e., if the IPv6 destination is unicast, the link-layer destination MUST be unicast, and same with multicast in place of unicast. The reason why I am asking this is that the current situation makes security design tricky. That is, the Secure ND part of SEND (as opposed to Secure RD) is all about creating a secure binding between an IP address and a link layer address. => this problem is the same than creating a secure binding between a DNS name and an IP address (i.e., the DNSSEC one). The WG decided to pursue the idea of using public key based AH to secure the NA (and NS) messages. That requires that the hosts learn the public keys of the other hosts on the local link. Basically, there are two know methods for distributing the public keys: Using certificates and relying on a (local) CA, or using Cryptographically Generated Addresses (CGA). => I stronly disagree: CGAs are very different: they don't provide authentication, only ownership. And there is a third way, Key-Based Addresses (KBA), i.e., the opposite of CGAs. Now, for zero-config operation, we would like to use the CGA ideas. Furthermore, there is a possible attack against link local addresses, and that attack can be partially dwarfed if we bind both the link layer address and the public key to the IP address in CGA. Under the current design, the CGA processing at the AH layer becomes very tricky, if we attempt to include the link layer address into the CGA process. => I don't understand your problem: with public keys you can sign NAs so secure the IPv6 to link-layer address binding. To secure the reverse binding we can reuse inverse ND (RFC 3122). So the only issue (:-) is the public key distribution... 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 12 08:16:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CGGeQb011505; Wed, 12 Feb 2003 08:16:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CGGd4A011504; Wed, 12 Feb 2003 08:16:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CGGaQb011497 for ; Wed, 12 Feb 2003 08:16:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CGGjVK024236 for ; Wed, 12 Feb 2003 08:16:45 -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 JAA24574 for ; Wed, 12 Feb 2003 09:16:36 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 434838514; Wed, 12 Feb 2003 11:16:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 11:16:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Testing tool for out IPv6 stack. Date: Wed, 12 Feb 2003 11:16:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED4@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Testing tool for out IPv6 stack. Thread-Index: AcLSpHaiSvH9ofXfSrCryCMDt9EEpAADG+ew From: "Bound, Jim" To: "sasson, shuki" , X-OriginalArrivalTime: 12 Feb 2003 16:16:32.0189 (UTC) FILETIME=[1B2F46D0:01C2D2B2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CGGaQb011498 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The standard benchmarks suites (e.g. Webstone, FPA, NFSstone, etc) have not been ported to this date to my knowledge. What we had to do is get our QA folks to port the stress tests to IPv6. I will assume you are integrating IPv6 into IPv4 stack? If so, then it is important for the following: 1. Should not break IPv4 applications 2. IPv4 should not perform less because IPv6 added to the stack. 3. Applications should be able to use either Ipv4 or IPv6 and testing this tells you a lot about your stack. 4. Can you make IPv6 perform better is the key. For base conformance you can get tests done by TAHI in Japan, University of New Hampshire in U.S. and ETSI in Europe. Also SPIRENT does good conformance tests. For interoperability testing which is completely different than running a test suite you have to get your machine in the above labs and let them beat on it and attend events for testing from the above places and go to places like Connectathon sponsored by Sun Microsystems in San Jose and there is one in a few weeks if your ready. For an IPv6 ONLY stack. Things get more complicated because some of the test "assumptions" change and some new ones we don't have now need to be created. Bottom line take the IPv4 stress and QA tools you have now and port them to use IPv6 is required to do a thorough job to state an IPv6 product can be deployed in a production network with all the liabilities such as statement implies for IPv4 today to your customers. Regards, /jim >-----Original Message----- >From: sasson, shuki [mailto:sasson_shuki@emc.com] >Sent: Wednesday, February 12, 2003 9:36 AM >To: ipng@sunroof.eng.sun.com >Subject: Testing tool for out IPv6 stack. > > >Hi all, we are developing an IPv6 stack for our products. I >wander if you can recommend us for a good testing tool for the >IPv6 stack. > >Thanks, > >Shuki Sasson >Principal Engineer, Network Storage Group > EMC² >where information lives > >Phone: 508 305 8515 >FaxNo: 508 435 8901 >Pager: 877 919 0794 >Email: sasson_shuki@emc.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 12 08:41:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CGfJQb011829; Wed, 12 Feb 2003 08:41:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CGfIf2011828; Wed, 12 Feb 2003 08:41:18 -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.8+Sun/8.12.8) with ESMTP id h1CGfEQb011815 for ; Wed, 12 Feb 2003 08:41:14 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1CGfFP26066; Wed, 12 Feb 2003 17:41:16 +0100 (MET) Date: Wed, 12 Feb 2003 17:37:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt To: itojun@iijlab.net, ettikan.kandasamy.karuppiah@intel.com Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, mrw@windriver.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 I've finally re-reviewed draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt. I have some concerns about clarity as well as strong concerns about the document seeming to change the standard for DNS clients verifying the source address of the replies. Details below. RFC 3258 uses the term "shared-unicast address" for what you seem to be calling "pseudo-anycast". I wonder if it makes sense using this existing term instead of creating a new one. RFC 3258 talks about an organization using anycast internally while speaking BGP to the external world, yet in section 2.2 you bundle this with draft-ietf-dnsop-ohta-shared-root-server-02.txt and seem to say that they both cross AS boundaries. As I understand it the technical difference between 3258 and shared-root-server is whether it is contained within one AS or not. Thus it would make sense to make this more clear in the document. Currently section 2.2 seems to only speak about the ohta approach, and my understanding is that the RFC 3258 approach is more widely deployed for DNS. I think RFC 3258's shared-unicast approach is quite useful given the constraints it imposes on itself: - used for DNS lookups i.e. short transactions - that the DNS has a failure recovery mechanism (through multiple NS records and multiple nameservers in resolv.conf) which provides failure recovery even though the routes are not withdrawn when an instance of the shared-unicast service dies. To make this more clear you can either remove the mention of BGP and "distant domains" from section 2.2 or you can make it clear what the Hardie and Ohta-san documents have in common and what is different (with the "distant domains" being the difference). I think it would be very useful to point out in section 3.3 that there is nothing inherent in IPv6 that prevents the use of pseudo-anycast - the issues listed in section 3.4 apply to both IPv4 and IPv6. I don't think there is WG concensus to endorse such behavior for IPv6 even through the scheme used in the Hardie and Ohta-san documents would work just as well (or poorly) in IPv6 as in IPv4. I don't understand what the last paragraph in section 4.1 is trying to say. Clearly carrying /128 routes for anycast word-wide doesn't scale for arbitrary use of anycast (but having explicit routes e.g. for DNS root servers isn't an abitrary use since the set of addresses would be very limited). Whether site-locals or globals are used it is required that the anycast addresses aggregate into existing prefix routes at some scale. But is the paragraph trying to say that this is some improvement that is needed? (It is in a section about possible improvements.) It can be read as this being something that needs to be fixed, but I think it is just a fundamental constraint whether anycast addresses are assigned to only routers or also to hosts. Thus the point seems to belong in section 1. Section 5.1 says: Note that, however, bad guys can still inject fabricated results to the client, even if the client checks the source address of the reply. The check does not improve security of the exchange at all. This seems counter to the wisdom that lead to requiring the addresses to match, yet you don't refute those arguments. I think in reality the (very spotty but existing) application of ingress filtering in the 'net means that the DNS requirement on matching addresses in requests and replies provide a non-zero security improvement. I think it is a bad idea to have an informational document like this try to change the DNS protocol practise to not check the source address of the reply. If you want to change this we need a standards track document. Having this informational document discuss the issue of source address checking is fine, but it isn't fine that it effectively removes it. o For many of the existing protocols, we cannot perform sanity checks using IP source address address. More specifically, for UDP DNS replies against queries to anycast address, it is not recommended to check source address, based on RFC2181 section 4.1. I don't see any text in section 4.1 in 2181 that recommends changing anything on the client. In fact section 4 and 4.1 is how to make servers work with clients that do verify the source address of the reply. Thus I can't see how you come to this conclusion. Section 7: For secure anycast operation, we may need to enable security mechanisms in other protocols. For example, if we were to inject /128 routes from end hosts by using a routing protocol, we may need to configure the routing protocol to exchange routes securely, to prevent malicious parties from injecting bogus routes. "exchange routes securely" reads like securing the exchange of the routes between the host and the router. That is useful but inadequate. The difficult problem is how the router knows which host is *authorized* to inject a route for which anycast address. Securing the communication between the host and router doesn't solve the authorization problem. It would make sense to point this out as an unsolved problem (short of manual configuration) in the draft. 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 12 09:09:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CH9KQb012025; Wed, 12 Feb 2003 09:09:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CH9KVb012024; Wed, 12 Feb 2003 09:09:20 -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.8+Sun/8.12.8) with ESMTP id h1CH9GQb012017 for ; Wed, 12 Feb 2003 09:09:17 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1CH9JP29407; Wed, 12 Feb 2003 18:09:20 +0100 (MET) Date: Wed, 12 Feb 2003 18:05:38 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Brian E Carpenter Cc: Michel Py , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3E48C575.5F43A6C6@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with Michel. Although Thomas is logically correct, > I think that including section 2.0 and putting this on > standards track is a necessary signal to ensure that TLAs > are really understood to be dead. If you want to be explicit about TLA/NLA being dead why not have a section 2.0 titled "TLA and NLA are dead" with a shortish explanation of why and with an informational reference to the registries document? > I also think the explicit reference to 2000::/3 is useful. > It's the only space currently being allocated. Because this might confuse people that they should only code for 2000::/3 in their implementation? We tried to make this clear in addr-arch-v3 (hopefully clear enough) but this document is not clear enough on that issue. Since RFCs live forever the "currently being allocated" argument might not be a good argument. Finally, assuming that this document isn't going standardize anything (now that the documentation prefix is removed) I think it makes sense having be an informational document that is part of a protocol action which moves RFC 2374 to historic. Only if this document standardizes some replacement to 2374 would it make sense for it to be proposed standard. Examples of "move to historic" documents are RFC 3197 and RFC 3167. They tend to explain why and what is being made historic with varying levels of detail. 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 12 09:13:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHDlQb012124; Wed, 12 Feb 2003 09:13:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CHDl7o012123; Wed, 12 Feb 2003 09:13:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHDhQb012113 for ; Wed, 12 Feb 2003 09:13:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CHDqVL012929 for ; Wed, 12 Feb 2003 09:13:52 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11938 for ; Wed, 12 Feb 2003 10:13:46 -0700 (MST) Message-ID: <00e301c2d2b9$d91c2bc0$846015ac@T23KEMPF> From: "James Kempf" To: "Bound, Jim" , "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> Subject: Re: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 09:11:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But isn't there a simple attack in which the attacker sends an NA message out with the victim's link layer address in the option but its own address on the frame? Naturally, if the link layer allows the attacker to send out frames under a false address, it could fully spoof the victim as well. jak ----- Original Message ----- From: "Bound, Jim" To: "Pekka Nikander" ; "IPV6 WG" Cc: "SEND WG" Sent: Wednesday, February 12, 2003 6:30 AM Subject: RE: Reason for the explicit link-layer address options in ND? > Hi Pekka, > > I can give you one answer and recall the discussion very well in > Cambridge MA well at an early interim IPng WG meeting (~1995) and this > is where we agreed to solicited node mulitcast archictecture principle, > as a note too. > > For Neighbor Discovery (ND) RFC 2461: > IPv4 and OSI too and many other previous implementations of a Internet > like network paradigm relied on address resoluton and node discovery at > the link layer of the network stack in conjunction with peeking at the > link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer, > Router Redirects, and ARP-Like funcitons were brought up to be part of > the IP layer processing, which is one of the clear advantages of IPv6 > IMO that we often don't tout (though steve brings this point out in his > masters and other talks). There is an architecture and implementation > reason. > > Architecturally this affords ND to be part of the IP(v6) layer and part > of the extensibility of that architecture as required (e.g. new ICMP > types, Routing Options, Destination Options). This can be seen from the > DNS Discovery deliberation and suggestion to use new ICMP type for > finding ones DNS server on a stateless network. It can be seen in Next > Header chain. With ARP or ES-IS this was not possible. In those > archictectures the address resolution and node discovery are disjoint > from the actual "virtual" layer 3 processing. > > >From implementation perspective it supports the principle of > cohesiveness when building the network subsystem. What this means is > that the code points for IP processing are now integral to the ND > methods and concepts like NUD and prefix assimilation from ND are now > part of the IP stack code base. NUD and prefix assimilation (just two > examples as a note) are part of ND architecture and support that > principle. The "implementors" of IPv6 and SIP (initial predecessor to > IPv6 and IPng choice) learned the implementation advantages of ND > methods and its place in the IPv6 architecture over implementations they > had done for ARP and ES-IS. > > So it was a win for the Architecture, Implemenation, and combined the > best from multiple methods previously done for address resolution, node > discovery, and router redirects. The last win was only possible by > integrating into the the IP layer. > > IPv6 Stateless Autoconfiguration RFC 2462. > This just adhered to the base packet types of ND and then added the > processes. > > The reason the link layer addresses are options was to permit > extensibility for ND and Autoconfig to be extensible to the win list > above of which address resolution and node discovery were only part. > Another reason is support future models for proxy and passing link-layer > addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was > to support the use of the Override bit which can be part of address > resolution and node discovery during first phase when link-layer > addresses are not shared or to inform implementation this is temporary > do not update your NUD cache. > > The reason for not peeking at the link layer in ND or Autoconfig is > separation of function within the IP architecture. There is no > requirement for this in previous models like ARP and ES-IS. If you look > at public domain network kernel implementations of BSD or Linux > derivations you will see the Ether (*) routines exist and for multiple > adapter types. Also you might want to look at the various IPv6 over Foo > specs that deal with how to deal with different link layer types. The > check with the link-layer is a link layer function not an IP layer > issue. In fact it is done on most implementations before the packet > comes off the interrupt queue to hit the IP layer. > > Lastly if there is a bug here it would be caught in the NUD state > machine and time out. > > Regards, > /jim > > > > > >-----Original Message----- > >From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > >Sent: Wednesday, February 12, 2003 8:43 AM > >To: IPV6 WG > >Cc: SEND WG > >Subject: Reason for the explicit link-layer address options in ND? > > > > > >On the behalf of the SEND DT, I'd like to get > >a clarification to the current ND design from > >those who were around back when RFC2461 and > >RFC2462 were written. > > > >Specifically, we'd like the know the exact > >reasons why RFC2461 uses separate source/target link > >layer address options instead of relying on the > >actual source link layer addresses used in the > >link layer frame? Furthermore, why are the actual > >link layer addresses used in the link layer frame > >completely ignored, and not checked to match with > >the options? > > > >Is this just a layering question, an attempt to > >avoid layer violations? Or were there behind > >other goals, like allowing proxy ND? > > > >The reason why I am asking this is that the current > >situation makes security design tricky. That is, > >the Secure ND part of SEND (as opposed to Secure RD) > >is all about creating a secure binding between an IP > >address and a link layer address. > > > >The WG decided to pursue the idea of using public > >key based AH to secure the NA (and NS) messages. > >That requires that the hosts learn the public keys > >of the other hosts on the local link. Basically, > >there are two know methods for distributing the > >public keys: Using certificates and relying on > >a (local) CA, or using Cryptographically Generated > >Addresses (CGA). > > > >Now, for zero-config operation, we would like to > >use the CGA ideas. Furthermore, there is a possible > >attack against link local addresses, and that attack > >can be partially dwarfed if we bind both the link > >layer address and the public key to the IP address > >in CGA. > > > >Under the current design, the CGA processing at the > >AH layer becomes very tricky, if we attempt to include > >the link layer address into the CGA process. > > > >--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 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 09:35:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHZaQb012546; Wed, 12 Feb 2003 09:35:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CHZaGR012545; Wed, 12 Feb 2003 09:35:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHZWQb012538 for ; Wed, 12 Feb 2003 09:35:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CHZfVL019894 for ; Wed, 12 Feb 2003 09:35:41 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27232 for ; Wed, 12 Feb 2003 09:35:36 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8627489B1; Wed, 12 Feb 2003 12:35:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 12:35:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 12:35:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLSuhpS0mGHyhQiQc+SmibvXvgJtAAAcV+g From: "Bound, Jim" To: "James Kempf" , "Pekka Nikander" , "IPV6 WG" Cc: "SEND WG" X-OriginalArrivalTime: 12 Feb 2003 17:35:35.0471 (UTC) FILETIME=[2666ABF0:01C2D2BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CHZXQb012539 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >But isn't there a simple attack in which the attacker sends an >NA message out with the victim's link layer address in the >option but its own address on the frame? Naturally, if the >link layer allows the attacker to send out frames under a >false address, it could fully spoof the victim as well. Yes but it will be found out with first packet to that node because it will not be delivered and time out and removed from the cache of the victim worst case. Best case the disconnect between Ehterlike (*) and IP layer will catch it immediately. But it is a clear DOS and can happen in ARP, ES-IS, et al. I would argue if this is a problem then IPsec can be used before ICMP in ND. And this has been implemented by some. I would think most SA verification code happens at the IP layer when the packet is received by routine like ip_input (v4 or v6) and IPsec mandates all packets be checked for SA. Now a bad person could still do this with IPsec if they got the key, received authorization from the authority etc. But there will be no perfect security ever IMO. The other point is except for the mobile nodes roaming the link is secure at layer -0 (the link in the building and your not allowed in the building without an identification per the armed guards). But for public links this is an issue and for wireless nodes but that is the work for SEND to do is my belief. I think you need to look at using IPsec as one method. But redefining the ND or Addrconf architecture should not be in the SEND charter. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 09:54:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHs6Qb012710; Wed, 12 Feb 2003 09:54:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CHs6IC012709; Wed, 12 Feb 2003 09:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CHs3Qb012702 for ; Wed, 12 Feb 2003 09:54:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CHsBVK025457 for ; Wed, 12 Feb 2003 09:54:11 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00014 for ; Wed, 12 Feb 2003 09:54:06 -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 JAA22090; Wed, 12 Feb 2003 09:54:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1CHs2o02435; Wed, 12 Feb 2003 09:54:02 -0800 X-mProtect: <200302121754> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdo4SYwW; Wed, 12 Feb 2003 09:54:00 PST Message-ID: <3E4A8AB9.4000406@iprg.nokia.com> Date: Wed, 12 Feb 2003 09:56:09 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <200302121458.h1CEwIof095565@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > Is this just a layering question, an attempt to > avoid layer violations? Or were there behind > other goals, like allowing proxy ND? > > => both reasons. In the same kind of design ideas, it is > forbidden to mix unicast and multicast between layers, i.e., > if the IPv6 destination is unicast, the link-layer destination > MUST be unicast, and same with multicast in place of unicast. Can you point me to the text that forbids this? I was under the impression that multicast emulation mechanisms (e.g. MARS, etc.) use unicast link-layer destination addresses when the IPv6 destination is multicast. The whole point of multicast emulation is to propagate network-layer multicasts over unicast-only link layers - not true? Thanks, Fred ftemplin@iprg.nokia.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 12 10:17:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CIGxQb013278; Wed, 12 Feb 2003 10:16:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CIGxVJ013277; Wed, 12 Feb 2003 10:16:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CIGtQb013264 for ; Wed, 12 Feb 2003 10:16:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CIH4VL004109 for ; Wed, 12 Feb 2003 10:17:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18625; Wed, 12 Feb 2003 10:16:58 -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 KAA23462; Wed, 12 Feb 2003 10:16:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1CIGuD27265; Wed, 12 Feb 2003 10:16:56 -0800 X-mProtect: <200302121816> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvhLUoL; Wed, 12 Feb 2003 10:16:54 PST Message-Id: <4.3.2.7.2.20030212093546.029e33b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Feb 2003 10:12:43 -0800 To: Erik Nordmark From: Bob Hinden Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Cc: Brian E Carpenter , Michel Py , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <3E48C575.5F43A6C6@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, At 09:05 AM 2/12/2003, Erik Nordmark wrote: > > I agree with Michel. Although Thomas is logically correct, > > I think that including section 2.0 and putting this on > > standards track is a necessary signal to ensure that TLAs > > are really understood to be dead. I too agree with this view. I tried to write this draft to be as uncontroversial as possible so it could proceed quickly and accomplish the goal of replacing RFC2374. >If you want to be explicit about TLA/NLA being dead why not have >a section 2.0 titled "TLA and NLA are dead" >with a shortish explanation of why and with an informational reference >to the registries document? Care to suggest some text? > > I also think the explicit reference to 2000::/3 is useful. > > It's the only space currently being allocated. > >Because this might confuse people that they should only code for 2000::/3 >in their implementation? I don't see how one could come to this conclusion. The draft was written to only cover the 2000::/3 prefix because the document it is obsoleting also only covers that prefix. For example from section 2.0 of RFC2374: This document defines an address format for the 001 (binary) Format Prefix for Aggregatable Global Unicast addresses. The same address format could be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the "001" Format Prefix is defined here. Making it apply to other prefixes seemed out of scope to me. >We tried to make this clear in addr-arch-v3 (hopefully clear enough) but >this document is not clear enough on that issue. What did you have in mind that might further clarify this issue? >Since RFCs live forever the "currently being allocated" argument might >not be a good argument. > > >Finally, assuming that this document isn't going standardize anything >(now that the documentation prefix is removed) I think it makes >sense having be an informational document that is part of a protocol >action which moves RFC 2374 to historic. >Only if this document standardizes some replacement to 2374 would it make >sense for it to be proposed standard. > >Examples of "move to historic" documents are RFC 3197 and RFC 3167. >They tend to explain why and what is being made historic with varying levels >of detail. While I don't feel too strongly about that status of the document, I share the belief that is important to send a "strong" message. Perhaps classifying it as a BCP might be a good middle ground. 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 12 12:09:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CK9nQb014902; Wed, 12 Feb 2003 12:09:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CK9nLR014901; Wed, 12 Feb 2003 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CK9jQb014894 for ; Wed, 12 Feb 2003 12:09:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CK9sVL013206 for ; Wed, 12 Feb 2003 12:09:54 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06883 for ; Wed, 12 Feb 2003 12:09:49 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 12 Feb 2003 12:09:48 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Feb 2003 12:09:48 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Wed, 12 Feb 2003 12:09:48 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 12 Feb 2003 12:09:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 12 Feb 2003 12:09:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Wed, 12 Feb 2003 12:09:16 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt thread-index: AcLN0x8VGo9fNJOCQH6oRh5Ju9xNrAEfdo9wACAnVTA= From: "Christian Huitema" To: "Bound, Jim" , Cc: X-OriginalArrivalTime: 12 Feb 2003 20:09:30.0990 (UTC) FILETIME=[A73308E0:01C2D2D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CK9kQb014895 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It should be SHOULD. The M bit means "use" Tasteful. The "O" bit means > use Stateful. Two different contexts. I was here when they were put in > ND and recall why. One reason is that not everyone believed that just > stateless was acceptable and that was vision on those persons part. We had a conclusive discussion off this point during the interim WG meeting in Sunnyvale. The reasoning goes as follow: if we want to maximize interoperability, we want to have a single mandatory address configuration procedure, not two; everybody agrees that we must support stateless address configuration; thus we should make stateless mandatory, and other configuration methods optional. This is properly reflected in section 5.3 (nodes MAY support DHCPv6), in section 4.5.2 (MUST support stateless) and in the current text of section 4.5.5, which is just fine. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 12:11:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CKBcQb014924; Wed, 12 Feb 2003 12:11:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CKBc2i014923; Wed, 12 Feb 2003 12:11:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CKBYQb014913 for ; Wed, 12 Feb 2003 12:11:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CKBhVK013449 for ; Wed, 12 Feb 2003 12:11:43 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08313 for ; Wed, 12 Feb 2003 12:11:36 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4F40E6A907; Wed, 12 Feb 2003 22:11:35 +0200 (EET) Message-ID: <3E4AAA64.60802@kolumbus.fi> Date: Wed, 12 Feb 2003 22:11:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: James Kempf , Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED8@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: > But it is a clear DOS and can happen in ARP, ES-IS, et al. I would > argue if this is a problem then IPsec can be used before ICMP in ND. > And this has been implemented by some. I would think most SA > verification code happens at the IP layer when the packet is received by > routine like ip_input (v4 or v6) and IPsec mandates all packets be > checked for SA. Yes, though you run into a couple of practical problems when you actually try to do this, namely problems getting IKE to run before you can send UDP packets, and the relatively large number of manual SAs if manual keying is used (2*n+2 SAs per node where n is the number of interface ids on the network, or something like that). > The other point is except for the mobile nodes roaming the link is > secure at layer -0 (the link in the building and your not allowed in the > building without an identification per the armed guards). But for > public links this is an issue and for wireless nodes but that is the > work for SEND to do is my belief. I think you need to look at using > IPsec as one method. But redefining the ND or Addrconf architecture > should not be in the SEND charter. Exactly, so that's why SEND is actually trying to use IPsec and Pekka is asking clarifications on why certain things are like they are in ND. We are working on the problems mentioned above. Work still remains, as you can see one of the issues we are thinking about is the relevance of link layer addresses and what checks are necessary or possible. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 12 13:45:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CLjJQb016154; Wed, 12 Feb 2003 13:45:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1CLjICf016153; Wed, 12 Feb 2003 13:45:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1CLjFQb016146 for ; Wed, 12 Feb 2003 13:45:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1CLjOVL015554 for ; Wed, 12 Feb 2003 13:45:24 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22738 for ; Wed, 12 Feb 2003 13:45:18 -0800 (PST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Feb 2003 13:45:12 -0800 Reply-To: From: "Tony Hain" To: "'Fred L. Templin'" , "'Francis Dupont'" Cc: "'Pekka Nikander'" , "'IPV6 WG'" , "'SEND WG'" Subject: RE: Reason for the explicit link-layer address options in ND? Date: Wed, 12 Feb 2003 13:45:02 -0800 Message-ID: <01e801c2d2df$fffaed50$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <3E4A8AB9.4000406@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1CLjGQb016147 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is an explicit unjustified one-liner in 1812 (pg 34): A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address. While it is clearly the intent of the security do-gooders to avoid arp cache pollution as a dos tool, there is a vast difference between 'SHOULD NOT do this without explicit intent', and 'MUST NOT do this'. As you point out there are cases where multicast over unicast makes sense, and there are cases where IP-anycast over multicast link layer make sense for load sharing. Unfortunately, the line above ends up as the basis for declarations that the types have to match. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Fred L. Templin > Sent: Wednesday, February 12, 2003 9:56 AM > To: Francis Dupont > Cc: Pekka Nikander; IPV6 WG; SEND WG > Subject: Re: Reason for the explicit link-layer address options in ND? > > > Francis Dupont wrote: > > In your previous mail you wrote: > > > > Is this just a layering question, an attempt to > > avoid layer violations? Or were there behind > > other goals, like allowing proxy ND? > > > > => both reasons. In the same kind of design ideas, it is > forbidden to > > mix unicast and multicast between layers, i.e., if the IPv6 > > destination is unicast, the link-layer destination MUST be unicast, > > and same with multicast in place of unicast. > > Can you point me to the text that forbids this? I was under > the impression that multicast emulation mechanisms (e.g. > MARS, etc.) use unicast link-layer destination addresses when > the IPv6 destination is multicast. The whole point of > multicast emulation is to propagate network-layer multicasts > over unicast-only link layers - not true? > > Thanks, > > Fred > ftemplin@iprg.nokia.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 12 16:22:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D0MUQb016739; Wed, 12 Feb 2003 16:22:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1D0MUBr016738; Wed, 12 Feb 2003 16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D0MRQb016731 for ; Wed, 12 Feb 2003 16:22:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1D0MZVL005480 for ; Wed, 12 Feb 2003 16:22:35 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04546 for ; Wed, 12 Feb 2003 17:22:29 -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 QAA07510; Wed, 12 Feb 2003 16:22:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1D0MR404461; Wed, 12 Feb 2003 16:22:27 -0800 X-mProtect: <200302130022> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYM4y4B; Wed, 12 Feb 2003 16:22:25 PST Message-Id: <4.3.2.7.2.20030212155845.02375130@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Feb 2003 16:21:57 -0800 To: "Christian Huitema" From: Bob Hinden Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt 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 I agree with this and think that a MUST for stateless and MAY for DHCP is fine. Bob (with no hats on) >We had a conclusive discussion off this point during the interim WG >meeting in Sunnyvale. The reasoning goes as follow: if we want to >maximize interoperability, we want to have a single mandatory address >configuration procedure, not two; everybody agrees that we must support >stateless address configuration; thus we should make stateless >mandatory, and other configuration methods optional. > >This is properly reflected in section 5.3 (nodes MAY support DHCPv6), in >section 4.5.2 (MUST support stateless) and in the current text of >section 4.5.5, which is just fine. > >-- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 18:47:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D2lbQb017131; Wed, 12 Feb 2003 18:47:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1D2lbKC017130; Wed, 12 Feb 2003 18:47:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D2lYQb017123 for ; Wed, 12 Feb 2003 18:47:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1D2lhVL013919 for ; Wed, 12 Feb 2003 18:47:43 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08040 for ; Wed, 12 Feb 2003 18:47:37 -0800 (PST) Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Wed, 12 Feb 2003 18:47:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BF3@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLR1Kf7Nz85DA2JSMmQkcpvVPlLiABLOh3g From: "Michel Py" To: "Thomas Narten" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1D2lYQb017124 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas / Brian / Bob, >> Michel Py wrote: >> Thomas, I can't argue with any of your other points, but you >> might want to include the need to wrap this up soon in the >> equation. I have not contributed what is in this message >> before because I did not want to delay the process, and that >> stuff still can wait, IMHO. > Thomas Narten wrote: > The above could be read to suggest that this document is so > important that no changes are appropriate at this point. I > have hard time with that, given that we've needed this > document for something like 2+ years, and it has been a mere > 10 days since the -00 version appeared. There is some truth to this, although this document was not the concern but draft-ietf-ipngwg-addr-arch-v3-11.txt going forward. It is even more urgent that we obsolete RFC2373 than 2374. Per some traffic on a RIPE list today, some people are still stuck with EUI-64 in their mind, this is not good. Since I don't recall this being discussed before, I made (possibly wrongly) the default assumption that the author's intentions were to do a pair of documents in the standard tracks that would be a one-for-one replacement of 2373/2374. To the extent that I could try to second-guess Pekka, I think that I am not the only one. Someone please debunk me if needed, but I have in the back of my mind that if addr-arch has not been published yet is because it's waiting for this document to ship. Hence the "importance". >> Michel Py wrote: >> In short: the bottom line is that the site boundary is now defined >> by RFC3177, which is what the RIRs call a semi-hard boundary. Given >> the intricate relations with architecture and scope, I don't see >> how a reference to it could be left out of the standards track. > Thomas Narten wrote: > Per above, this is not part of the architecture. This is policy > (and good policy, IMO). I do not think it is appropriate to hard > wire this into our specifications. I am not proposing that we change this. All that I was trying to say is that I would have wished to give more importance to 3177, but if the consensus is that we have declared victory once and for all, so be it whether I like it or not. I have done my job reminding the list that although RFC3177 is policy, it still has some strong ties to architecture. I think that what I'm not happy about is that as an afterthought I would have preferred 3177 to be BCP. > IMO, we should declare victory and stop worrying about this. > There is no need to for the IETF to make further statements > about the /48 boundary at this time. I would also argue that > it is wrong to try to push that boundary into an architecture > or standards track document, I would agree that it is wrong to push that boundary back into architecture, but I think we went one step too far from having it in the architecture to the point that we say "we don't know, we don't care and we don't even want to hear about it." > as there is no technical implication on implementations. There might be a need later. In MHAP, I have a hard /48 boundary for optimization purposes. I needs to be debated whether or not it's a good idea in that context, but I think that we should not totally close the door to going back to a thinking that might be a little harder on the boundary. > (Indeed, rather the opposite -- we take great steps to ensure > that no implementation will incorrectly assume such a boundary > exists and hard code it into the implementation.) I agree for the basic IPv6 stack, but again there could be some future spin-offs. > Yes. Obsoleting 2374 is (from what I can tell) the point of this > document. IMO, putting more into the document than needed to > achieve just this is a distraction. Mmmm. I still think that what Bob did trying to sneak in the documentation prefix was a good idea, since he also pulled it at the first sign of trouble. > Brian Carpenter wrote: > If the draft attempted to make a normative reference to 3177, > it would be a blunder. > .... > It's a very light reference to 3177. I think it's useful to make > the point that the RIR policy and the IAB/IESG recommendation are > consistent. It's a footnote though. Reluctantly settles for a footnote. > Bob Hinden wrote: > While I don't feel too strongly about that status of the document, > I share the belief that is important to send a "strong" message. > Perhaps classifying it as a BCP might be a good middle ground. I'm with Bob and Brian on the "strong" signal, a BCP would be a good way to reach consensus. 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 12 22:02:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D62lQb017537; Wed, 12 Feb 2003 22:02:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1D62l66017536; Wed, 12 Feb 2003 22:02:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D62hQb017529 for ; Wed, 12 Feb 2003 22:02:43 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1D62qVK028098 for ; Wed, 12 Feb 2003 22:02:52 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12088 for ; Wed, 12 Feb 2003 22:02:46 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C689360D0; Thu, 13 Feb 2003 01:02:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 01:02:45 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 01:02:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06DD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLS0vZvHDnFRzSNRdirGAaY3VTo/gAUhLZA From: "Bound, Jim" To: "Jari Arkko" Cc: "James Kempf" , "Pekka Nikander" , "IPV6 WG" , "SEND WG" X-OriginalArrivalTime: 13 Feb 2003 06:02:45.0771 (UTC) FILETIME=[875795B0:01C2D325] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1D62iQb017530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > > > But it is a clear DOS and can happen in ARP, ES-IS, et al. I would > > argue if this is a problem then IPsec can be used before > ICMP in ND. > > And this has been implemented by some. I would think most SA > > verification code happens at the IP layer when the packet > is received > > by routine like ip_input (v4 or v6) and IPsec mandates all > packets be > > checked for SA. > > Yes, though you run into a couple of practical problems when > you actually try to do this, namely problems getting IKE to > run before you can send UDP packets, and the relatively large > number of manual SAs if manual keying is used (2*n+2 SAs per > node where n is the number of interface ids on the network, > or something like that). The IKE UDP issue is only an implementation issue the spec works. We have known this about manual keying since the beginnning. IPsec will work and with IKE. > > > The other point is except for the mobile nodes roaming the link is > > secure at layer -0 (the link in the building and your not > allowed in > > the building without an identification per the armed > guards). But for > > public links this is an issue and for wireless nodes but > that is the > > work for SEND to do is my belief. I think you need to look > at using > > IPsec as one method. But redefining the ND or Addrconf architecture > > should not be in the SEND charter. > > Exactly, so that's why SEND is actually trying to use IPsec > and Pekka is asking clarifications on why certain things are > like they are in ND. We are working on the problems mentioned > above. Work still remains, as you can see one of the issues > we are thinking about is the relevance of link layer > addresses and what checks are necessary or possible. Clarification is good. Was the spec not clear? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 12 22:10:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D6AXQb017631; Wed, 12 Feb 2003 22:10:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1D6AXPY017630; Wed, 12 Feb 2003 22:10:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D6ATQb017622 for ; Wed, 12 Feb 2003 22:10:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1D6AcVK029271 for ; Wed, 12 Feb 2003 22:10:38 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26855 for ; Wed, 12 Feb 2003 22:10:33 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A784C3419; Thu, 13 Feb 2003 01:10:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 01:10:32 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 01:10:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLN0x8VGo9fNJOCQH6oRh5Ju9xNrAEfdo9wACAnVTAAFP3RAA== From: "Bound, Jim" To: "Christian Huitema" , Cc: X-OriginalArrivalTime: 13 Feb 2003 06:10:32.0564 (UTC) FILETIME=[9D928B40:01C2D326] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1D6ATQb017623 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > It should be SHOULD. The M bit means "use" Tasteful. The "O" bit > means > > use Stateful. Two different contexts. I was here when > they were put > in > > ND and recall why. One reason is that not everyone > believed that just > > stateless was acceptable and that was vision on those persons part. > > We had a conclusive discussion off this point during the > interim WG meeting in Sunnyvale. The reasoning goes as > follow: if we want to maximize interoperability, we want to > have a single mandatory address configuration procedure, not > two; everybody agrees that we must support stateless address > configuration; thus we should make stateless mandatory, and > other configuration methods optional. I was at the meeting. I did not hear consensus for this at all or in mail follow up or at Atlanta. I don't believe all agree with this view at all and I know all the users don't and all the vendors don't and all on this list. So what do you mean by all? > > This is properly reflected in section 5.3 (nodes MAY support > DHCPv6), in section 4.5.2 (MUST support stateless) and in the > current text of section 4.5.5, which is just fine. The reason I did not object to that is because DHCPv6 had not reached proposed standard I will have to think if I object to that now that you bring it up. But DHCPv6 is just one method of Statefull we know today, and probably should be a MAY but now will think on that too. So the two references are orthognal. Besides M there is O bit. That means use statefull for other configuration and that is another issue. The implementation of M and O bit should be a SHOULD. I do not believe we have consensus on the view you state above. Nor do I believe that all discussion points have been brought forth for such an important decision. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 01:43:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D9hTQb018271; Thu, 13 Feb 2003 01:43:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1D9hTtB018270; Thu, 13 Feb 2003 01: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1D9hOQb018263 for ; Thu, 13 Feb 2003 01:43:25 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1D9hQP02391; Thu, 13 Feb 2003 10:43:26 +0100 (MET) Date: Thu, 13 Feb 2003 10:39:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Bob Hinden Cc: Erik Nordmark , Brian E Carpenter , Michel Py , Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20030212093546.029e33b0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >If you want to be explicit about TLA/NLA being dead why not have > >a section 2.0 titled "TLA and NLA are dead" > >with a shortish explanation of why and with an informational reference > >to the registries document? > > Care to suggest some text? RFC 2374 contained an IPv6 allocation structure that included TLA (Top Level Aggregator) and NLA (Next Level Aggregator) which is formally made historic by this document. The TLA/NLA scheme has been replaced by an coordinated allocation policy defined by the Regional Internet Registries [REF]. Part of the motivations for obsoleting the TLA/NLA structure were technical, for instance there was concerns that it was not the technically best approach at this point in time on IPv6 deployment. Another part of the motivation was that the issues of how the IPv6 address space is managed is much more related to policy and to the the stewardship of the IP address space and routing table size that the RIRs have been managing for IPv4. It is likely that the RIRs policy will evolve as IPv6 deployment proceeds. The IETF has provided technical input to the RIRs (for example [RFC 3177]) that has been taken into account when defining the policy. > >Because this might confuse people that they should only code for 2000::/3 > >in their implementation? > > I don't see how one could come to this conclusion. > > The draft was written to only cover the 2000::/3 prefix because the > document it is obsoleting also only covers that prefix. For example from > section 2.0 of RFC2374: I agree that RFC 2374 only covers that prefix. But that doesn't mean that the docment which makes 2374 historic needs to have the same limitation. > What did you have in mind that might further clarify this issue? Remove "for the 2000::/3 Prefix" from the title and remove the mention of the specific prefix from the text. Apart from the restriction to 2000::/3 I don't see how section 2.0 adds anything beyond what is in addr-arch. Perhaps I'm missing something. > While I don't feel too strongly about that status of the document, I share > the belief that is important to send a "strong" message. Perhaps > classifying it as a BCP might be a good middle ground. But the strong message would be that there would be an IETF last call saying that RFC 2374 is moving to historic and this doc informational. Then this will be permanently recorded in rfc-index with 2374 being marked as historic. This seems to be strong enough for other protocols/documents we've made historic such as RIPv1 (with RFC 1923 being the info doc that explains why). 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 13 02:46:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DAkTQb018494; Thu, 13 Feb 2003 02:46:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DAkTmt018493; Thu, 13 Feb 2003 02:46:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DAkQQb018486 for ; Thu, 13 Feb 2003 02:46:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DAkaVK017675 for ; Thu, 13 Feb 2003 02:46:36 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20363 for ; Thu, 13 Feb 2003 02:46:30 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BD25E6A906; Thu, 13 Feb 2003 12:46:23 +0200 (EET) Message-ID: <3E4B776B.4060708@kolumbus.fi> Date: Thu, 13 Feb 2003 12:46:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: James Kempf , Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B034C06DD@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > The IKE UDP issue is only an implementation issue the spec works. We > have known this about manual keying since the beginnning. IPsec will > work and with IKE. Yes, the manual keying issue is mostly implementation, or rather configuration. But the IKE issue is more fundamental than just implementation. For one, Neighbor Discovery uses multicast extensively and IKE of course only handles unicast. So from the start we can't really use dynamic keying for all of ND. Furthermore, even if you would ignore multicast, some chicken-and-egg problems remain. For instance, assume that we need to talk to a peer, and do address resolution first. If all unicast traffic between the two peers is expected to be secured, this would imply that a solicited NA would have to be secured as well. But in order to secure the NA, we would need IKE to send IP packets to the peer, which in turn would require us to see the NA first, right? So it doesn't really work as of now. >>Exactly, so that's why SEND is actually trying to use IPsec >>and Pekka is asking clarifications on why certain things are >>like they are in ND. We are working on the problems mentioned >>above. Work still remains, as you can see one of the issues >>we are thinking about is the relevance of link layer >>addresses and what checks are necessary or possible. > > > Clarification is good. Was the spec not clear? I think we now have gotten more information on the role of the link-layer addresses in ND and why they are not checked. Thanks. I'm personally leaning towards leaving link-layer address checks away from SEND. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 13 02:53:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DAr2Qb018583; Thu, 13 Feb 2003 02:53:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DAr1i9018582; Thu, 13 Feb 2003 02:53:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DAqwQb018575 for ; Thu, 13 Feb 2003 02:52:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DAr7VL004015 for ; Thu, 13 Feb 2003 02:53:07 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08984 for ; Thu, 13 Feb 2003 03:53:01 -0700 (MST) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 53B281C; Thu, 13 Feb 2003 13:01:34 +0200 (EET) Message-ID: <3E4B7905.9080706@nomadiclab.com> Date: Thu, 13 Feb 2003 12:52:53 +0200 From: Pekka Nikander Reply-To: SEND WG , Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG , SEND WG , Jim.Bound@hp.com, Francis.Dupont@enst-bretagne.fr Subject: Summary: Reason for the explicit link-layer address options in ND? References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks, Jim and Francis, for your timely answers to my question. Yes, like Jari pointed out, we are working on using IPsec for SEND, and we need to understand ND better to make it *right*. However, that discussion belongs to the very silent SEND mailing list, and should be continued only there, IMHO. (I've inserted Reply-To: headers to facilitate that...) Now, the ND specs as such are clear. No problem with that. It is just that the design rationale behind the specs in not written anywhere (as usual), and that was the reason for asking my question. We are not attempting to redefine or even revise the ND architecture, we are attempting to understand it fully so that we can design proper security for it. Now, if I read correctly what you Jim and Francis are saying, there seems to be a number of reasons for the design. Please correct me if I get this wrong; I am rewriting what I read to see if I understand it correctly. 1. Architecture It was deemed architecturally good to place ND at the IP/ICMP layer rather than below it. The main benefits from this are the following: - allows extension headers to be used - allows IPsec protection for ND - allows using routing and destination options 2. Implementation Early implementation experience showed that as a consequence of the design, implementation becomes simpler. In particular, NUD and prefix assimilation become part of the IP layer. I have one further question about that: what do you mean with prefix assimilation? I didn't find the term in RFC2461 or RFC2462. The reasons for the link layer address options were the following: 3. Extensibility (with extension headers etc). This seems to be a direct consequence of the architectural design decision. 4. Support for future functionality like proxy ND Again, this seems to follow the architectural principle layed out above. 5. Better support for the Override bit Now, I have a question about the Override bit. I didn't quite understand how it could be used for "node discovery during first phase when link-layer addresses are not shared". What did you mean with that, Jim? Finally, the reasons for not peeking at the actual link layer addresses used in the link layer frame can be summarized as follows: 6. Separation of function This again follows the architectural principle. Especially, it was viewed that checking the link-layer addresses is a link layer function, and it should be separate from the IP layer. Is that all or am I missing something? Or is there something above that doesn't belong there? Now, if you want to discuss how security fits in this all, may I suggest that we do it on the SEND list? (Personally I have trouble in keeping track with the IPv6 list volume, as I have also other things to do but participate to the IETF work.) --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 Thu Feb 13 05:04:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DD4UQb019137; Thu, 13 Feb 2003 05:04:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DD4UAF019136; Thu, 13 Feb 2003 05:04:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DD4QQb019129 for ; Thu, 13 Feb 2003 05:04:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DD4ZVL023644 for ; Thu, 13 Feb 2003 05:04:35 -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 GAA25444 for ; Thu, 13 Feb 2003 06:04:29 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 04A3088CF; Thu, 13 Feb 2003 08:04:29 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 08:04:28 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 08:04:28 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE0@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary: Reason for the explicit link-layer address options in ND? Thread-Index: AcLTThKvTgZ6ugIFSYegV1gMMQZRvAADqEKQ From: "Bound, Jim" To: "SEND WG" , "Pekka Nikander" , "IPV6 WG" , X-OriginalArrivalTime: 13 Feb 2003 13:04:28.0935 (UTC) FILETIME=[71340170:01C2D360] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1DD4RQb019130 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > Thanks, Jim and Francis, for your timely answers to my > question. Yes, like Jari pointed out, we are working on > using IPsec for SEND, and we need to understand ND better to > make it *right*. However, that discussion belongs to the > very silent SEND mailing list, and should be continued only > there, IMHO. (I've inserted Reply-To: headers to facilitate that...) I am fine with the strategy. > > Now, the ND specs as such are clear. No problem with > that. It is just that the design rationale behind the > specs in not written anywhere (as usual), and that was > the reason for asking my question. We are not attempting > to redefine or even revise the ND architecture, we are > attempting to understand it fully so that we can design > proper security for it. OK. I just get nervous lately esp with researchers who want to help make IPv6 better. I have an issue when a person shows up at the hospital with a headache and the hospital takes the patient to a room for open heart surgery. Glad that is not the case. Also I asked the question also to yet again show in our community taking time to put rationale appendices in completed standards specs is a wise thing to do as the IEEE does. Oh well I must try. > > Now, if I read correctly what you Jim and Francis are saying, > there seems to be a number of reasons for the design. Please > correct me if I get this wrong; I am rewriting what I read to > see if I understand it correctly. > > 1. Architecture > > It was deemed architecturally good to place ND > at the IP/ICMP layer rather than below it. The > main benefits from this are the following: > > - allows extension headers to be used > - allows IPsec protection for ND > - allows using routing and destination options These are attributes yes. To get them all a detailed investigation of ND would need to be done. Do these work for now? > > 2. Implementation > > Early implementation experience showed that as > a consequence of the design, implementation becomes > simpler. In particular, NUD and prefix assimilation > become part of the IP layer. > > I have one further question about that: what do > you mean with prefix assimilation? I didn't find > the term in RFC2461 or RFC2462. Sorry I knew that when I wrote it and did it anyway, sorry again. In ND a node can receive prefixes for autoconfiguration and to be used to note prefixes on that link or just one or just both. L bit says this prefix can be used for onlink determination and A bit says this prefix can be used for addrconf. The ability to have this knowledge about prefixes permits the verification of other nodes on the network. So if a rogue prefix appears a hint can be provided it is not on link valid from the L bit. But the code to work prefix vs link-layer is two separate functions that can be then joined for verification and assimilation to support ND caches and the NUD state machine. Does that help? > > > The reasons for the link layer address options were > the following: > > 3. Extensibility (with extension headers etc). > > This seems to be a direct consequence of the > architectural design decision. Specifically with ICMP and new types. If a new ICMP SEND type were needed you would not have to reinvent the link-layer packets "hopefully". > > 4. Support for future functionality like proxy ND > > Again, this seems to follow the architectural > principle layed out above. > > 5. Better support for the Override bit > > Now, I have a question about the Override bit. > I didn't quite understand how it could be used > for "node discovery during first phase when > link-layer addresses are not shared". > > What did you mean with that, Jim? The override bit if on says don't replace this link-layer with existing link-layer or if not set do replace it. Throughout 2461 this bit is used to control state and cache replacement. This is very powerful and a real advantage of ND over its predecessors. Also in SEND I would look to see if there are conditions that can be set with the override bit for initial security benefits. > > Finally, the reasons for not peeking at the actual > link layer addresses used in the link layer frame can > be summarized as follows: > > 6. Separation of function > > This again follows the architectural principle. > Especially, it was viewed that checking the > link-layer addresses is a link layer function, > and it should be separate from the IP layer. > > Is that all or am I missing something? Or is there > something above that doesn't belong there? Yes this is the only reason. But see the IPv6 over foo specs. > > Now, if you want to discuss how security fits in this > all, may I suggest that we do it on the SEND list? > (Personally I have trouble in keeping track with > the IPv6 list volume, as I have also other things > to do but participate to the IETF work.) I This makes sense. I don't have the time to take SEND on. But if you have direct questions and send them I will go look within a reasonable time frame. I implemented parts of ND and all of Addrconf so know them well from that but that was some time ago too and even an implementor has to go recheck specs. Also we did identify this potential security issue in the spec under considerations briefly speaking of it as MAC spoofing. If SEND puts out spec saying in additon to whats in ND implementations should also do X I see that as goodness. Just don't want to see 2461 altered unless something is broken in ND itself is my input to our processes. Regards, /jim > > --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 Thu Feb 13 05:15:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DDFZQb019259; Thu, 13 Feb 2003 05:15:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DDFZ2I019258; Thu, 13 Feb 2003 05:15:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DDFVQb019251 for ; Thu, 13 Feb 2003 05:15:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DDFeVL025363 for ; Thu, 13 Feb 2003 05:15:40 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14419 for ; Thu, 13 Feb 2003 06:15:34 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 84DB975F6; Thu, 13 Feb 2003 08:15:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 08:15:32 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reason for the explicit link-layer address options in ND? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 08:15:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason for the explicit link-layer address options in ND? Thread-Index: AcLTTTM5AshzMngCS2+XiK43DOE4DAAE3Ivw From: "Bound, Jim" To: "Jari Arkko" Cc: "James Kempf" , "Pekka Nikander" , "IPV6 WG" , "SEND WG" X-OriginalArrivalTime: 13 Feb 2003 13:15:32.0420 (UTC) FILETIME=[FCABC840:01C2D361] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1DDFWQb019252 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > But the IKE issue is more fundamental than just > implementation. For one, Neighbor Discovery uses multicast > extensively and IKE of course only handles unicast. So from > the start we can't really use dynamic keying for all of ND. > Furthermore, even if you would ignore multicast, some > chicken-and-egg problems remain. For instance, assume that we > need to talk to a peer, and do address resolution first. If > all unicast traffic between the two peers is expected to be > secured, this would imply that a solicited NA would have to > be secured as well. But in order to secure the NA, we would > need IKE to send IP packets to the peer, which in turn would > require us to see the NA first, right? So it doesn't really > work as of now. I believe the multicast keying problem for link-local is resolvable but that is an IPsec discussion right? Agreed for multicast past the link. OK. In this sense your right I thought you were concerned about the IKE process to get keys. Which is valid but I believe they can be preconfigured before the node is on the network too. In fact a model that I believe will become more prevalent over time esp handhelds. Yes the NA in normal environment is required but not all. Once the node has a link-local address it could be congfigured at boot time to load a key. We do this today in industry for licenses etc. When the IPv6 node is booting and does DAD to get link-local address verified it then goes and gets its key. The key can then be used for the NA and NS processes. The hole that is open widest to an attack is DAD. That would be very hard to fix. As I said we will never have perfect security any more than other aspects of life. I would argue you SEND should see what it can do to extend security to the mobile node and the link it enters via ND at the point of getting a link-local adddress. If that is more secure it will reduce many other attacks. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 08:19:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DGJLQb020154; Thu, 13 Feb 2003 08:19:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DGJLUl020153; Thu, 13 Feb 2003 08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DGJIQb020146 for ; Thu, 13 Feb 2003 08:19:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DGJRVK020729 for ; Thu, 13 Feb 2003 08:19:27 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20579; Thu, 13 Feb 2003 09:19:21 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1DGJ5Xp047398; Thu, 13 Feb 2003 17:19:05 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1DGJ4fO242904; Thu, 13 Feb 2003 17:19:05 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42406 from ; Thu, 13 Feb 2003 17:18:59 +0100 Message-Id: <3E4BC542.E0767A7F@hursley.ibm.com> Date: Thu, 13 Feb 2003 17:18:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Erik Nordmark Cc: Bob Hinden , Michel Py , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: ... > > What did you have in mind that might further clarify this issue? > > Remove "for the 2000::/3 Prefix" from the title and remove > the mention of the specific prefix from the text. > > Apart from the restriction to 2000::/3 I don't see how section 2.0 adds > anything beyond what is in addr-arch. Perhaps I'm missing something. It doesn't add anything but it clarifies things that many people who are not on this list have misunderstood (or they have read in text books with obsolete content). I really think it is useful text. It should mention 2000::/3 in my opinion, because we are *redefining* the way we use 2000::/3. But it should indeed point out that architecturally, 2000::/3 is not special. Since it is somewhat redundant with addr-arch, I now agree that Informational is OK. 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 Thu Feb 13 09:17:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DHHIQb020559; Thu, 13 Feb 2003 09:17:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DHHIK8020558; Thu, 13 Feb 2003 09:17:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DHHFQb020551 for ; Thu, 13 Feb 2003 09:17:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DHHNVL022757 for ; Thu, 13 Feb 2003 09:17:23 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27421 for ; Thu, 13 Feb 2003 10:17:17 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1DHHDh02084; Thu, 13 Feb 2003 18:17:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1DHFHof099887; Thu, 13 Feb 2003 18:15:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302131715.h1DHFHof099887@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Fred L. Templin" cc: Pekka Nikander , IPV6 WG , SEND WG Subject: Re: Reason for the explicit link-layer address options in ND? In-reply-to: Your message of Wed, 12 Feb 2003 09:56:09 PST. <3E4A8AB9.4000406@iprg.nokia.com> Date: Thu, 13 Feb 2003 18:15: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: Francis Dupont wrote: > In your previous mail you wrote: > > Is this just a layering question, an attempt to > avoid layer violations? Or were there behind > other goals, like allowing proxy ND? > > => both reasons. In the same kind of design ideas, it is > forbidden to mix unicast and multicast between layers, i.e., > if the IPv6 destination is unicast, the link-layer destination > MUST be unicast, and same with multicast in place of unicast. Can you point me to the text that forbids this? => RFC 1122 3.3.6 but I recognize this needs to be clarify for IPv6. I was under the impression that multicast emulation mechanisms (e.g. MARS, etc.) use unicast link-layer destination addresses when the IPv6 destination is multicast. => in the case of MARS for ATM there is no real link-layer addresses for the point-to-multipoint virtual circuits. Even if MCS are used in fact we can argue the link-layer address is a set of addresses with possible indirection. The whole point of multicast emulation is to propagate network-layer multicasts over unicast-only link layers - not true? => yes but the special mark for link-layer broadcast/multicast packets is still needed. Regards Francis.Dupont@enst-bretagne.fr PS: the exact quote is (see also TCP/IP illustrated V2 page 1101): When a host sends a datagram to a link-layer broadcast address, the IP destination address MUST be a legal IP broadcast or IP multicast address. A host SHOULD silently discard a datagram that is received via a link-layer broadcast (see Section 2.4) but does not specify an IP multicast or broadcast destination 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 Thu Feb 13 09:55:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DHtAQb021009; Thu, 13 Feb 2003 09:55:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DHtAFU021008; Thu, 13 Feb 2003 09:55:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DHt7Qb020999 for ; Thu, 13 Feb 2003 09:55:07 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DHtGVK019378 for ; Thu, 13 Feb 2003 09:55:16 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15198 for ; Thu, 13 Feb 2003 09:55:10 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Thu, 13 Feb 2003 09:55:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BF9@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcLR+lduOgIVjCX0SfSu90LPpbF2mQBjJytA From: "Michel Py" To: "Alan E. Beard" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1DHt7Qb021002 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan, Excellent post, thanks. I just have two things to comment. > Alan E. Beard wrote: > managers who chose to play ostrich (you know what that > bird exposes when it sticks its head in the sand) That must be the same place some stick their heads when there's no sand around. The cat and the hanging ones are so true, too. > I strongly suspect that end-user networks will not embrace > IPv6 enthusiastically unless registered, globally routable > PI space is readily available. I will modulate this by saying that end-user networks don't necessarily want straight PI, they want the perks that come with it. Although it is clear that nothing will be as simple as straight PI, it does come with a hefty price, the size of the routing table, that we are not ready to pay yet. When we come up with an identifier/locator system that provides the same perks, the reduction of the routing table will be a worthy trade-off for the oddities that will come with the identifier/locator. 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 13 10:49:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DInfQb021460; Thu, 13 Feb 2003 10:49:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DInf0v021459; Thu, 13 Feb 2003 10:49:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DIncQb021452 for ; Thu, 13 Feb 2003 10:49:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DInlVL024876 for ; Thu, 13 Feb 2003 10:49:47 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27545 for ; Thu, 13 Feb 2003 10:49:41 -0800 (PST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1DInX9c050293; Thu, 13 Feb 2003 13:49:33 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1DInWNx047930; Thu, 13 Feb 2003 13:49:32 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1DInWY6047927; Thu, 13 Feb 2003 13:49:32 -0500 (EST) Date: Thu, 13 Feb 2003 13:49:32 -0500 (EST) From: "Alan E. Beard" To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BF9@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030213134153.Q43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Feb 2003, Michel Py wrote: > > Alan E. Beard wrote: > > I strongly suspect that end-user networks will not embrace > > IPv6 enthusiastically unless registered, globally routable > > PI space is readily available. > > I will modulate this by saying that end-user networks don't necessarily > want straight PI, they want the perks that come with it. Although it is > clear that nothing will be as simple as straight PI, it does come with a > hefty price, the size of the routing table, that we are not ready to pay > yet. When we come up with an identifier/locator system that provides the > same perks, the reduction of the routing table will be a worthy > trade-off for the oddities that will come with the identifier/locator. > > Michel. > Yes, I think you are probably right in speculating that any technically sound mechanism which preserves the virtues of provider independence, portability, and stability in configuration of end-user-network devices will satisfy the functional requirements of the end-user community. It seems to be up to us to architect the mechanism(s). Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 12:08:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DK8rQb022339; Thu, 13 Feb 2003 12:08:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DK8rKe022338; Thu, 13 Feb 2003 12:08:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DK8nQb022331 for ; Thu, 13 Feb 2003 12:08:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DK8wVK006434 for ; Thu, 13 Feb 2003 12:08:58 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26869 for ; Thu, 13 Feb 2003 13:08:52 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA18426 for ; Thu, 13 Feb 2003 20:08:51 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1DK8nY2024565 for ; Thu, 13 Feb 2003 20:08:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1DK8ns04641 for ipng@sunroof.eng.sun.com; Thu, 13 Feb 2003 20:08:49 GMT Date: Thu, 13 Feb 2003 20:08:49 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Message-ID: <20030213200849.GI3595@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F5B9DA@server2000.arneill-py.sacramento.ca.us> <5E32DF8C-3D9A-11D7-874A-000393AB1404@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E32DF8C-3D9A-11D7-874A-000393AB1404@kurtis.pp.se> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Feb 11, 2003 at 09:25:24AM +0100, Kurt Erik Lindqvist wrote: > > 1) Address space shortage > 2a) No scalable PI solution > 2b) No scalable IDR solution > > I said it before and I will say it again, without a solution to 2a, no > enterprises will go to IPv6, with no enterprises on IPv6 there are no > revenues for the ISPs in IPv6, with no revenue from IPv6 the ISPs will > not go to IPv6. Just because I can reach a webpage over IPv6 doesn't > make the web-page more interesting. If it isn't more interesting I > can't charge extra for it. Going to IPv6 will cost the ISPs. Sorry. It > doesn't work out. We need to progress on multi6 if this is to take off. Yes, but not for all networks. I appreciate many people don't view the academic research networks as commercial networks, but there is a large potential IPv6 user base in that community for whom address stability has been available through pre-CIDR allocations. In the UK example, the 200 or so universities will go from 160 IPv4 (PI) prefixes to 1 single IPv6 (PA) prefix, but the provider being the non-commercial "independent" NREN makes the address space in effect PI (JANET has a /32 allocation). Each of the 25-30 European NRENs are likely to be in a similar position, so you could see 25-30 SubTLA's replacing (well, living alongside :) around 3,000 IPv4 prefixes. Behind those 25-30 SubTLAs are maybe 30 million staff and students at the universities. Well, that's one view. Many regional networks may seek to multihome. Some universities might seek SubTLA prefixes (many obtained pTLA space, and some are LIR's for the benefit of IPv4 multihoming, but multihoming to universities isn't common because they're tied in, for better or worse, richer or poorer, to the NREN service). I think multihoming is important in the shorter term for a number of classes of networks, including some large enterprises. IPv6 multihoming for home networks is further off, and is the point at which you would be looking at the "1 billion multihomers" scenario. But for some (many?) users/networks, multihoming isn't critical to adopt IPv6. 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 13 15:07:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DN7AQb025150; Thu, 13 Feb 2003 15:07:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1DN7AHr025149; Thu, 13 Feb 2003 15:07:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1DN77Qb025142 for ; Thu, 13 Feb 2003 15:07:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1DN7GVL002071 for ; Thu, 13 Feb 2003 15:07:16 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14270 for ; Thu, 13 Feb 2003 16:07:08 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1DN6X9c050785; Thu, 13 Feb 2003 18:06:33 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1DN6XNx048263; Thu, 13 Feb 2003 18:06:33 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1DN6WUQ048260; Thu, 13 Feb 2003 18:06:32 -0500 (EST) Date: Thu, 13 Feb 2003 18:06:32 -0500 (EST) From: "Alan E. Beard" To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <20030213200849.GI3595@login.ecs.soton.ac.uk> Message-ID: <20030213153051.H43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Kurt: I will add some comments from the end-user-network perspective on behalf of my client base. Please see inline. AEB On Thu, 13 Feb 2003, Tim Chown wrote: > On Tue, Feb 11, 2003 at 09:25:24AM +0100, Kurt Erik Lindqvist wrote: > > > > 1) Address space shortage > > 2a) No scalable PI solution > > 2b) No scalable IDR solution > > > > I said it before and I will say it again, without a solution to 2a, no > > enterprises will go to IPv6, with no enterprises on IPv6 there are no > > revenues for the ISPs in IPv6, with no revenue from IPv6 the ISPs will > > not go to IPv6. Just because I can reach a webpage over IPv6 doesn't > > make the web-page more interesting. If it isn't more interesting I > > can't charge extra for it. Going to IPv6 will cost the ISPs. Sorry. It > > doesn't work out. We need to progress on multi6 if this is to take off. > Most end-user network managers I deal with require these characteristics of their public network address allocations: 1) uniqueness (sometimes expressed as "autonomy") 2) portability 3) stability In many cases, requirement two is driven by a desire to implement multiple connections to the public networks via more than one service provider (multihoming). While PI is not an absolute requirement, the present state of our technology and standards (for v6 as well as v4) force us to PI as the only implemented mechanism which satisfies the functional requirements enumerated above. If we can develop and write into the standards some alternate mechanisms which are technically sound and will meet these functional requirements, we can perhaps avoid the persistent and vocal demands from the end-user community for PI; until that time, however, PI will remain a key requirement from end-user network managers. > Yes, but not for all networks. I appreciate many people don't view the > academic research networks as commercial networks, but there is a large > potential IPv6 user base in that community for whom address stability has > been available through pre-CIDR allocations. In the UK example, the 200 > or so universities will go from 160 IPv4 (PI) prefixes to 1 single IPv6 > (PA) prefix, but the provider being the non-commercial "independent" NREN > makes the address space in effect PI (JANET has a /32 allocation). Each > of the 25-30 European NRENs are likely to be in a similar position, so > you could see 25-30 SubTLA's replacing (well, living alongside :) around > 3,000 IPv4 prefixes. Behind those 25-30 SubTLAs are maybe 30 million staff > and students at the universities. > For those end-user-network managers who are aware of the details of the NREN allocations, this situation provokes pure, incandescent fury: the academic entities are seen as having been granted special (and grossly preferential) treatment, while the commercial (as distinguished from service-provider) networks are subject to callous indifference and excluded thereby from direct access to stable network address allocations. We can't even claim "separate but equal" for this state of affairs, and the universal principle of Brown V. Board of Education still holds, even for networks. [For those not familiar with recent US history, send me mail directly for a brief explanation of the above reference. AEB] > Well, that's one view. Many regional networks may seek to multihome. Some > universities might seek SubTLA prefixes (many obtained pTLA space, and some > are LIR's for the benefit of IPv4 multihoming, but multihoming to universities > isn't common because they're tied in, for better or worse, richer or poorer, > to the NREN service). > > I think multihoming is important in the shorter term for a number of classes > of networks, including some large enterprises. IPv6 multihoming for home > networks is further off, and is the point at which you would be looking at > the "1 billion multihomers" scenario. But for some (many?) users/networks, > multihoming isn't critical to adopt IPv6. > > Tim Most of the end-user-network managers among my clients now multihome, and will continue to require multihomed service in future. In every case where the user's network is multihomed, the multiple independent connections are seen as crucial for maintenance of high availability of the client's services to the public networks; and high availability is considered an absolute requirement for survival of the business. In some cases there are regulatory requirements which can result in civil or administrative sanctions (including, in the worst event, loss of operating licenses) if the services should be found unavailable for significant periods of time. Yes, it is possible, at least in theory, for commercial service providers to sustain the required level of availability, but most of my clients have found, much to their distress, that the US ISPs are almost uniformly incapable of doing so in practice. In almost every case, the administrative managers for these user networks are simply and flatly unwilling to put their businesses at the mercy of a single ISP. Based on conversations with my clients, I cannot find it within the scope of my imagination (or, for that matter, of theirs) that these networks will give up the mutilhoming requirement at any time within the foreseeable future. Now granted, many of the networks referred to above provide access to financial services, so the uptime requirements may be slightly more rigorous than average; however, I cannot imagine that any business which generates substantial portions of its revenue from systems which rely on network access would fail to impose stringent availability requirements on network service, particularly since these businesses go to quite extraordinary lengths to ensure availability of the online systems themselves. Home networks may be another matter, but I would give my eyeteeth to get a stable, portable (and, thereby, multihome-capable) IPv6 allocation for _my_ home network, as that network also supports supports my office and business-related systems. (And, before you ask, all the systems - but not necessarily all the peripherals - in my network _are_ v6-capable.) I suspect that we will find increasing use of "home" networks for business activity, and increasing demand for stability of network locator information. Granted, DNS provides some stability in network locator information, but it is still not sufficient to overcome the current ISP practices of enforced address instability and service restrictions, and I can see no incentive (short of PI) in the current proposals which augurs a change in current ISP policy and pricing. As it is, I pay quite outrageous fees to secure for my office public-network access which is sufficiently reliable and stable to sustain the business, and I _still_ can't multihome. Based on experience with my client base, I cannot agree with the postulate that many networks will not find lack of multihome support a barrier to implementation of v6. The current speculation about "what the users _really_ need" (as distinguished from what they _say_ they need) smacks to me of "all networks are equal, but some are more equal than others" (with apologies to _Animal Farm_). It seems to me that we have some technical problems to resolve here, and user education (or arbitrary restrictions on what services are available to some classes of users) will not resolve the extant issues, not even temporarily. These issues will continue to raise their ugly heads (or nether ends, and a I don't know how to distinguish one from the other at this point) until we engineer solutions to the technical problems - we can't "educate" or regulate these problems out of existence. That's my $.02 worth. Alan E. Beard -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 13 16:42:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E0giQb026923; Thu, 13 Feb 2003 16:42:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E0gh77026922; Thu, 13 Feb 2003 16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E0geQb026915 for ; Thu, 13 Feb 2003 16:42:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E0gnVL006873 for ; Thu, 13 Feb 2003 16:42:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14687; Thu, 13 Feb 2003 17:42: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 QAA25743; Thu, 13 Feb 2003 16:42:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1E0ghY29352; Thu, 13 Feb 2003 16:42:43 -0800 X-mProtect: <200302140042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTb8BwQ; Thu, 13 Feb 2003 16:42:41 PST Message-Id: <4.3.2.7.2.20030213153511.036d4608@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Feb 2003 16:42:11 -0800 To: Erik Nordmark From: Bob Hinden Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20030212093546.029e33b0@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 Erik, > > Care to suggest some text? > > RFC 2374 contained an IPv6 allocation structure that included > TLA (Top Level Aggregator) and NLA (Next Level Aggregator) which > is formally made historic by this document. > > The TLA/NLA scheme has been replaced by an coordinated allocation > policy > defined by the Regional Internet Registries [REF]. > > Part of the motivations for obsoleting the TLA/NLA structure > were technical, for instance there was concerns that it was not > the technically best approach at this point in time on IPv6 > deployment. > Another part of the motivation was that the issues of how the > IPv6 address space is managed is much more related to policy and > to the the stewardship of the IP address space and routing table > size that the RIRs have been managing for IPv4. It is likely that > the RIRs policy will evolve as IPv6 deployment proceeds. > > The IETF has provided technical input to the RIRs > (for example [RFC 3177]) that has been taken into account > when defining the policy. This is OK for me. I will plan add it to the next version of the draft. Would you like to be listed as an author? Any one else have comments on this change? > > > >Because this might confuse people that they should only code for 2000::/3 > > >in their implementation? > > > > I don't see how one could come to this conclusion. > > > > The draft was written to only cover the 2000::/3 prefix because the > > document it is obsoleting also only covers that prefix. For example from > > section 2.0 of RFC2374: > >I agree that RFC 2374 only covers that prefix. >But that doesn't mean that the docment which makes 2374 historic >needs to have the same limitation. > > > > What did you have in mind that might further clarify this issue? > >Remove "for the 2000::/3 Prefix" from the title and remove >the mention of the specific prefix from the text. OK, that is clearer. It wouldn't be too hard to make this change, but there doesn't seem to be complete agreement on the list for this change. >Apart from the restriction to 2000::/3 I don't see how section 2.0 adds >anything beyond what is in addr-arch. Perhaps I'm missing something. I think it provides a summary of what the resulting address format for this prefix (and other prefixes if the above change is made). Since we now seem to heading toward a non-standards track document, what is the harm? > > While I don't feel too strongly about that status of the document, I share > > the belief that is important to send a "strong" message. Perhaps > > classifying it as a BCP might be a good middle ground. > >But the strong message would be that there would be an IETF last call >saying that RFC 2374 is moving to historic and this doc informational. >Then this will be permanently recorded in rfc-index with 2374 being marked >as historic. > >This seems to be strong enough for other protocols/documents we've made >historic such as RIPv1 (with RFC 1923 being the info doc that explains >why). The RIPv1/v2 case seems fairly different to me, because the RIPv2 existed for a long time before RIPv1 was made historic. I now agree that it can be non-standards track. What was your objection to making it a BCP? In some ways this is the best current practice. 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 Thu Feb 13 17:55:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E1tVQb027378; Thu, 13 Feb 2003 17:55:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E1tVMT027377; Thu, 13 Feb 2003 17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E1tRQb027370 for ; Thu, 13 Feb 2003 17:55:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E1taVK025210 for ; Thu, 13 Feb 2003 17:55:36 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17925 for ; Thu, 13 Feb 2003 17:55:30 -0800 (PST) Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Thu, 13 Feb 2003 17:55:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BFC@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLTwkjgi2QkqrHPQAGxYkaVg003NQABQqNg From: "Michel Py" To: "Bob Hinden" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1E1tSQb027371 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > [Erik's text] > Any one else have comments on this change? Works for me. [the 2000::/3 prefix issue] Re-thinking it, my feelings are now that it would be good to remove it from the title, and that indeed it is no different than the TLA/NLA issue; in the same spirit than Erik's text, coining a sentence that says in substance that FP 001 is dead although 2000::/3 still the only range allocated for unicast use seems the way to go. In a sense, we could say that the same way TLAs and NLAs have disappeared to become RIR policy, FP 001 has disappeared to become IANA matter. Proposed title: "IPv6 Global Unicast Address Format" Proposed text: RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) which is formally made historic by this document. Although as specified in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 for now, IANA might allocate unassigned parts of the IPv6 address space to Global Unicast later. 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 13 21:03:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E53oQb027821; Thu, 13 Feb 2003 21:03:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E53oR5027820; Thu, 13 Feb 2003 21:03:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E53lQb027813 for ; Thu, 13 Feb 2003 21:03:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E53uVL004064 for ; Thu, 13 Feb 2003 21:03:56 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15718 for ; Thu, 13 Feb 2003 22:03:50 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA12048; Fri, 14 Feb 2003 00:03:47 -0500 (EST) Date: Fri, 14 Feb 2003 00:03:47 -0500 (EST) From: Dan Lanciani Message-Id: <200302140503.AAA12048@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Alan E. Beard" wrote: |Yes, I think you are probably right in speculating that any technically |sound mechanism which preserves the virtues of provider independence, |portability, and stability in configuration of end-user-network devices |will satisfy the functional requirements of the end-user community. It |seems to be up to us to architect the mechanism(s). Any thoughts on how we might jump start some activity in this area? Over the years I've tried the bottom-up approach by suggesting some possible mechanisms, and I've tried the top-down approach by suggesting that we try to reach consensus on how much overhead we are willing to accept in return for the solution. The former generally provokes protests that the solution is too complicated to sketch and the latter usually results in silence. How can we get some serious discussion going? If we do stick our heads in the sand (again) and pretend that provider-based hierarchical address allocation is temporary (again) then history will likely repeat itself. There will be a little v6 swamp to accommodate some edu sites and those enterprises that are big enough to demand real multi-homed support, but the rest of us will be stuck with the same kind of unstable/non-portable addresses we have today in the post-aggregation v4 world. IMHO, any solution that attacks the problem by slightly shifting the demarkation point so that "enough" large enterprises can have PI space to make v6 appear commercially viable is a sham. We cannot afford to defer support of the small- and home- office environment forever. 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 Thu Feb 13 22:24:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E6OxQb028153; Thu, 13 Feb 2003 22:24:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E6Owfi028152; Thu, 13 Feb 2003 22:24:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E6OtQb028145 for ; Thu, 13 Feb 2003 22:24:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E6P4VK018992 for ; Thu, 13 Feb 2003 22:25: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 kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11094 for ; Thu, 13 Feb 2003 23:24:59 -0700 (MST) Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Thu, 13 Feb 2003 22:24:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BFE@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLTRGBucKcLCacGTsS724Nau2TD7wAqvMRQ From: "Michel Py" To: "Erik Nordmark" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1E6OtQb028146 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik / ipv6 folk, > Erik Nordmark wrote: > RFC 2374 contained an IPv6 allocation structure that > included TLA (Top Level Aggregator) and NLA (Next > Level Aggregator) which is formally made historic by > this document. > The TLA/NLA scheme has been replaced by an coordinated > allocation policy defined by the Regional Internet > Registries [REF]. Part of the motivations for obsoleting > the TLA/NLA structure were technical, for instance there > was concerns that it was not the technically best > approach at this point in time on IPv6 deployment. > Another part of the motivation was that the issues of > how the IPv6 address space is managed is much more > related to policy and to the the stewardship of the IP > address space and routing table size that the RIRs have > been managing for IPv4. It is likely that the RIRs > policy will evolve as IPv6 deployment proceeds. > The IETF has provided technical input to the RIRs (for > example [RFC 3177]) that has been taken into account > when defining the policy. I was re-reading your text, and I have additional comments. [disclaimer: I have stated before that it was fine by me, and this still holds. If consensus is reached on the text you proposed the doc should be shipped without further delays.] That being said, I have contradictory / ambiguous feelings about the omission of "SLA". Here's the contradiction: - On one side, since you explicitly kill TLA and NLA but not SLA, it is permitted to think that SLA is not completely dead, which suits me fine since my position is that although moving it to policy was a good idea, killing the notion of site boundary was not. - On the other side, if SLA is not dead it's not alive either, which makes it a zombie I guess. This is not good, and one of these nights, when the moon is full, it will rise from the grave like in Michael Jackson's "thriller" and come haunt us. Therefore, we have three options for SLA: 1. Don't change the text and keep it a zombie. 2. Kill it (which I don't like). 3. Spare it; the idea being that what we want to do is move it to policy but don't kill the notion that a site boundary exists. This is what RIRs call a "soft" or "semi-hard" boundary. Comments welcome. 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 14 01:50:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9orQb028823; Fri, 14 Feb 2003 01:50:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E9or10028822; Fri, 14 Feb 2003 01:50:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9ooQb028815 for ; Fri, 14 Feb 2003 01:50:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9oxVK028366 for ; Fri, 14 Feb 2003 01:50:59 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28729 for ; Fri, 14 Feb 2003 01:50:50 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1E9oAhu024864; Fri, 14 Feb 2003 10:50:11 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1E9o99H012178; Fri, 14 Feb 2003 10:50:10 +0100 Received: from dhcp222-34.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27658 from ; Fri, 14 Feb 2003 10:50:06 +0100 Message-Id: <3E4CBB9C.7053C003@hursley.ibm.com> Date: Fri, 14 Feb 2003 10:49:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <963621801C6D3E4A9CF454A1972AE8F54BFC@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 OK for me Brian Michel Py wrote: > > Bob, > > > Bob Hinden wrote: > > [Erik's text] > > Any one else have comments on this change? > > Works for me. > > [the 2000::/3 prefix issue] > > Re-thinking it, my feelings are now that it would be good to remove it > from the title, and that indeed it is no different than the TLA/NLA > issue; in the same spirit than Erik's text, coining a sentence that says > in substance that FP 001 is dead although 2000::/3 still the only range > allocated for unicast use seems the way to go. In a sense, we could say > that the same way TLAs and NLAs have disappeared to become RIR policy, > FP 001 has disappeared to become IANA matter. > > Proposed title: "IPv6 Global Unicast Address Format" > > Proposed text: > > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 > for now, IANA might allocate unassigned parts of the IPv6 address space > to Global Unicast later. > > 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 14 01:54:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9sOQb028882; Fri, 14 Feb 2003 01:54:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E9sOEU028881; Fri, 14 Feb 2003 01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9sLQb028874 for ; Fri, 14 Feb 2003 01:54:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9sUVK029038 for ; Fri, 14 Feb 2003 01:54:30 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21250; Fri, 14 Feb 2003 01:54:22 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1E9sHTQ065066; Fri, 14 Feb 2003 10:54:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1E9sG9H140432; Fri, 14 Feb 2003 10:54:17 +0100 Received: from dhcp222-34.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47126 from ; Fri, 14 Feb 2003 10:54:14 +0100 Message-Id: <3E4CBC94.3FE88FF3@hursley.ibm.com> Date: Fri, 14 Feb 2003 10:53:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <963621801C6D3E4A9CF454A1972AE8F54BFE@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 On balance, I prefer ducking the issue in the draft we are discussing. If I get a /48 I have 16 bits for subnet addressing and I'm happy, so why worry about the acronym SLA? The RIRs have accepted the point (but I still want to see an informational reference to 3177 to ensure the paper trail is complete). Brian Michel Py wrote: > > Erik / ipv6 folk, > > > Erik Nordmark wrote: > > RFC 2374 contained an IPv6 allocation structure that > > included TLA (Top Level Aggregator) and NLA (Next > > Level Aggregator) which is formally made historic by > > this document. > > The TLA/NLA scheme has been replaced by an coordinated > > allocation policy defined by the Regional Internet > > Registries [REF]. Part of the motivations for obsoleting > > the TLA/NLA structure were technical, for instance there > > was concerns that it was not the technically best > > approach at this point in time on IPv6 deployment. > > Another part of the motivation was that the issues of > > how the IPv6 address space is managed is much more > > related to policy and to the the stewardship of the IP > > address space and routing table size that the RIRs have > > been managing for IPv4. It is likely that the RIRs > > policy will evolve as IPv6 deployment proceeds. > > The IETF has provided technical input to the RIRs (for > > example [RFC 3177]) that has been taken into account > > when defining the policy. > > I was re-reading your text, and I have additional comments. > > [disclaimer: I have stated before that it was fine by me, and this still > holds. If consensus is reached on the text you proposed the doc should > be shipped without further delays.] > > That being said, I have contradictory / ambiguous feelings about the > omission of "SLA". Here's the contradiction: > > - On one side, since you explicitly kill TLA and NLA but not SLA, it is > permitted to think that SLA is not completely dead, which suits me fine > since my position is that although moving it to policy was a good idea, > killing the notion of site boundary was not. > > - On the other side, if SLA is not dead it's not alive either, which > makes it a zombie I guess. This is not good, and one of these nights, > when the moon is full, it will rise from the grave like in Michael > Jackson's "thriller" and come haunt us. > > Therefore, we have three options for SLA: > 1. Don't change the text and keep it a zombie. > 2. Kill it (which I don't like). > 3. Spare it; the idea being that what we want to do is move it to policy > but don't kill the notion that a site boundary exists. This is what RIRs > call a "soft" or "semi-hard" boundary. > > Comments welcome. > > 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 14 04:52:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ECqdQb029752; Fri, 14 Feb 2003 04:52:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1ECqcWF029751; Fri, 14 Feb 2003 04:52:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ECqZQb029744 for ; Fri, 14 Feb 2003 04:52:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1ECqhVK027448 for ; Fri, 14 Feb 2003 04:52:43 -0800 (PST) Received: from c3po.skynet.be (c3po.skynet.be [195.238.3.237]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11717 for ; Fri, 14 Feb 2003 05:52:37 -0700 (MST) Received: from tsn (118.186-200-80.adsl.skynet.be [80.200.186.118]) by c3po.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with ESMTP id h1ECqIYO023071 for ; Fri, 14 Feb 2003 13:52:18 +0100 (MET) (envelope-from ) Message-Id: <200302141252.h1ECqIYO023071@c3po.skynet.be> From: "Mario Goebbels" To: Subject: Flexible address policy on 2000::/3? Date: Fri, 14 Feb 2003 13:52:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4523 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does this imply that the 13bit TLA of the initial addressing scheme is scrapped too? Thanks for any info. -mg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 06:03:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EE3CQb000155; Fri, 14 Feb 2003 06:03:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EE3CJZ000153; Fri, 14 Feb 2003 06:03:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EE38Qb000145 for ; Fri, 14 Feb 2003 06:03:08 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EE3HVK009369 for ; Fri, 14 Feb 2003 06:03:17 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10386 for ; Fri, 14 Feb 2003 06:03:11 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1EE2xWT097156; Fri, 14 Feb 2003 15:03:02 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1EE2Yn1291248; Fri, 14 Feb 2003 15:02:34 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17736 from ; Fri, 14 Feb 2003 15:02:31 +0100 Message-Id: <3E4CF6C5.16E4E23@hursley.ibm.com> Date: Fri, 14 Feb 2003 15:01:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Mario Goebbels Cc: ipng@sunroof.eng.sun.com Subject: Re: Flexible address policy on 2000::/3? References: <200302141252.h1ECqIYO023071@c3po.skynet.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mario Goebbels wrote: > > Does this imply that the 13bit TLA of the initial addressing scheme is > scrapped too? Yes. See http://www.ripe.net/ripe/docs/ipv6policy.html 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 14 07:07:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EF7AQb000643; Fri, 14 Feb 2003 07:07:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EF7ARt000642; Fri, 14 Feb 2003 07:07:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EF76Qb000635 for ; Fri, 14 Feb 2003 07:07:06 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EF7FVL008858 for ; Fri, 14 Feb 2003 07:07:15 -0800 (PST) Received: from zablv02002.vodacom.corp ([196.6.129.90]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16473 for ; Fri, 14 Feb 2003 07:03:23 -0800 (PST) Received: from mail pickup service by zablv02002.vodacom.corp with Microsoft SMTPSVC; Fri, 14 Feb 2003 17:03:05 +0200 Received: FROM mfwj023.mfw.is.co.za BY zablv02002.vodacom.corp ; Fri Feb 14 12:10:21 2003 +0200 Received: from patan.sun.com (not verified[192.18.98.43]) by mfwj023.mfw.is.co.za with MailMarshal (4,2,5,0) id ; Fri, 14 Feb 2003 12:08:27 +0200 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18252; Fri, 14 Feb 2003 02:52:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9pMVj018801; Fri, 14 Feb 2003 01:52:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9orQb028823; Fri, 14 Feb 2003 01:50:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E9or10028822; Fri, 14 Feb 2003 01:50:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9ooQb028815 for ; Fri, 14 Feb 2003 01:50:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9oxVK028366 for ; Fri, 14 Feb 2003 01:50:59 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28729 for ; Fri, 14 Feb 2003 01:50:50 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1E9oAhu024864; Fri, 14 Feb 2003 10:50:11 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1E9o99H012178; Fri, 14 Feb 2003 10:50:10 +0100 Received: from dhcp222-34.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27658 from ; Fri, 14 Feb 2003 10:50:06 +0100 Message-Id: <3E4CBB9C.7053C003@hursley.ibm.com> Date: Fri, 14 Feb 2003 10:49:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <963621801C6D3E4A9CF454A1972AE8F54BFC@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 15:03:05.0873 (UTC) FILETIME=[2DA45010:01C2D43A] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK for me Brian Michel Py wrote: > > Bob, > > > Bob Hinden wrote: > > [Erik's text] > > Any one else have comments on this change? > > Works for me. > > [the 2000::/3 prefix issue] > > Re-thinking it, my feelings are now that it would be good to remove it > from the title, and that indeed it is no different than the TLA/NLA > issue; in the same spirit than Erik's text, coining a sentence that says > in substance that FP 001 is dead although 2000::/3 still the only range > allocated for unicast use seems the way to go. In a sense, we could say > that the same way TLAs and NLAs have disappeared to become RIR policy, > FP 001 has disappeared to become IANA matter. > > Proposed title: "IPv6 Global Unicast Address Format" > > Proposed text: > > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 > for now, IANA might allocate unassigned parts of the IPv6 address space > to Global Unicast later. > > 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 Fri Feb 14 07:15:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFF5Qb001424; Fri, 14 Feb 2003 07:15:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EFF54J001423; Fri, 14 Feb 2003 07:15:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFF0Qb001404 for ; Fri, 14 Feb 2003 07:15:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EFF9VL010929 for ; Fri, 14 Feb 2003 07:15:09 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24133 for ; Fri, 14 Feb 2003 07:15:03 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3B6666A901 for ; Fri, 14 Feb 2003 17:15:02 +0200 (EET) Message-ID: <3E4D07E1.3010205@kolumbus.fi> Date: Fri, 14 Feb 2003 17:14:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG Subject: RFC 3041 clarification requested Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm trying to understand what the following text means and implies in Section 3.3 of RFC 3041: "Note: because multiple temporary addresses are generated from the same associated randomized interface identifier, there is little benefit in running DAD on every temporary address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier." Does this refer to multiple addresses when the link has multiple prefixes? Or when multiple temporary addresses are generated in sequence? It says "addresses generated from the given randomized identifier" so one might assume it means the multiple prefix case. But on the other hand the randomized identifier is also fed as history to the generation of new addresses, so it might mean the sequence also. Additionally, I'm wondering how DAD works with RFC 3041. The scheme appears to rely on the order in which addresses are generated. On a network with two prefixes A and B two nodes might not generate and test the addresses in the same order. For instance, node 1 could test A:: and node 2 could test B:: first. If the random values collide, the collision apparently isn't detected and both nodes proceed to use both A:: and B::. Or did I miss something? Also, it wasn't clear to me whether link-local addresses are generated for every new IID or not. If they are, RFC 2462 rules in Section 5.4 apply and the collision problem may be solved that way. (Or does it -- where does it say that "first" in 3041 refers to the link-local address?) 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 14 07:37:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFbpQb001836; Fri, 14 Feb 2003 07:37:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EFbpFc001835; Fri, 14 Feb 2003 07:37:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFbmQb001828 for ; Fri, 14 Feb 2003 07:37:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EFbuVK002988 for ; Fri, 14 Feb 2003 07:37:56 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24706 for ; Fri, 14 Feb 2003 07:37:51 -0800 (PST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1EFaxka055770 for ; Fri, 14 Feb 2003 10:37:13 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1EFavcn126822 for ; Fri, 14 Feb 2003 08:36:58 -0700 Importance: Normal Sensitivity: Subject: IPv6 MIB team: TCP-MIB in RFC2012 draft - tcpListenerTimeOuts To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Fri, 14 Feb 2003 10:36:56 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/14/2003 08:36:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have been looking into implementing TCP data from the version-neutral RFC2012 draft. We have a question about when the tcpListenerTimeOuts counter should be incremented given the following scenarios. We assume the counter should be incremented when the row is removed from the tcpConnectionTable while in the synReceived state _only if_ the removal was due to the retransmission of the SYN/ACK packets timing out. If the route from the client to the server is working but the route from the server back to the client is dropping packets, both the client and server's TCP/IP stacks will begin retransmitting packets. The client will retransmit the SYN packets and the server will retransmit the SYN/ACK reply. Because the SYN/ACK packets are dropped, this will continue until one or both sides time out. This can create unpredictable results as far as what the tcpListenerTimeOut counter will be. Here are some possible scenarios: a) The client and server retransmission intervals are approximately the same. The client times out first since it sent the first packet and sends a RST packet. The server receives the RST packet and removes the row from the tcpConnectionTable _before the server times out_. In this case the counter would _not_ be incremented at all. b) The client and server retransmission intervals are approximately the same. The client times out first since it sent the first packet and sends a RST packet. The server times out and removes the row from the tcpConnectionTable _before it processes the RST packet from the client_. In this case the counter would be incremented once. c) The client's retransmission interval have been configured to be longer than the server's intervals. The server might time out several times before the client eventually times out. When the server times out, it does send a RST packet, but because the packets are being dropped along this route, the client never receives the RST and continues to resend SYN packets. When the resent SYN is received by the server which just removed a row for the same local/remote IP address and port, it treats this packet as a new request and creates a new row in the tcpConnectionTable in synReceived state. The server could time out multiple times before the client times out causing the tcpListenerTimeOut counter to be incremented multiple times for a single connect() request. Is our understanding of when this counter is to be incremented correct? In the above scenarios, will the value reflect what the tcpListenerTimeOuts MIB object was intended to count? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 14 07:38:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFc7Qb001846; Fri, 14 Feb 2003 07:38:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EFc7J7001845; Fri, 14 Feb 2003 07:38:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFc0Qb001838 for ; Fri, 14 Feb 2003 07:38:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EFc8VK003034 for ; Fri, 14 Feb 2003 07:38:08 -0800 (PST) Received: from zablv02002.vodacom.corp ([196.6.129.90]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10664 for ; Fri, 14 Feb 2003 08:36:27 -0700 (MST) Received: from mail pickup service by zablv02002.vodacom.corp with Microsoft SMTPSVC; Fri, 14 Feb 2003 17:29:47 +0200 Received: FROM mfwj024.mfw.is.co.za BY ZACTN02002.vodacom.corp ; Fri Feb 14 11:59:42 2003 +0200 Received: from pheriche.sun.com (not verified[192.18.98.34]) by mfwj024.mfw.is.co.za with MailMarshal (4,2,5,0) id ; Fri, 14 Feb 2003 11:57:56 +0200 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24106; Fri, 14 Feb 2003 02:55:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9suVj019285; Fri, 14 Feb 2003 01:55:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9sOQb028882; Fri, 14 Feb 2003 01:54:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1E9sOEU028881; Fri, 14 Feb 2003 01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1E9sLQb028874 for ; Fri, 14 Feb 2003 01:54:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1E9sUVK029038 for ; Fri, 14 Feb 2003 01:54:30 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21250; Fri, 14 Feb 2003 01:54:22 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1E9sHTQ065066; Fri, 14 Feb 2003 10:54:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1E9sG9H140432; Fri, 14 Feb 2003 10:54:17 +0100 Received: from dhcp222-34.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47126 from ; Fri, 14 Feb 2003 10:54:14 +0100 Message-Id: <3E4CBC94.3FE88FF3@hursley.ibm.com> Date: Fri, 14 Feb 2003 10:53:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: <963621801C6D3E4A9CF454A1972AE8F54BFE@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 15:29:47.0310 (UTC) FILETIME=[E82C34E0:01C2D43D] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On balance, I prefer ducking the issue in the draft we are discussing. If I get a /48 I have 16 bits for subnet addressing and I'm happy, so why worry about the acronym SLA? The RIRs have accepted the point (but I still want to see an informational reference to 3177 to ensure the paper trail is complete). Brian Michel Py wrote: > > Erik / ipv6 folk, > > > Erik Nordmark wrote: > > RFC 2374 contained an IPv6 allocation structure that > > included TLA (Top Level Aggregator) and NLA (Next > > Level Aggregator) which is formally made historic by > > this document. > > The TLA/NLA scheme has been replaced by an coordinated > > allocation policy defined by the Regional Internet > > Registries [REF]. Part of the motivations for obsoleting > > the TLA/NLA structure were technical, for instance there > > was concerns that it was not the technically best > > approach at this point in time on IPv6 deployment. > > Another part of the motivation was that the issues of > > how the IPv6 address space is managed is much more > > related to policy and to the the stewardship of the IP > > address space and routing table size that the RIRs have > > been managing for IPv4. It is likely that the RIRs > > policy will evolve as IPv6 deployment proceeds. > > The IETF has provided technical input to the RIRs (for > > example [RFC 3177]) that has been taken into account > > when defining the policy. > > I was re-reading your text, and I have additional comments. > > [disclaimer: I have stated before that it was fine by me, and this still > holds. If consensus is reached on the text you proposed the doc should > be shipped without further delays.] > > That being said, I have contradictory / ambiguous feelings about the > omission of "SLA". Here's the contradiction: > > - On one side, since you explicitly kill TLA and NLA but not SLA, it is > permitted to think that SLA is not completely dead, which suits me fine > since my position is that although moving it to policy was a good idea, > killing the notion of site boundary was not. > > - On the other side, if SLA is not dead it's not alive either, which > makes it a zombie I guess. This is not good, and one of these nights, > when the moon is full, it will rise from the grave like in Michael > Jackson's "thriller" and come haunt us. > > Therefore, we have three options for SLA: > 1. Don't change the text and keep it a zombie. > 2. Kill it (which I don't like). > 3. Spare it; the idea being that what we want to do is move it to policy > but don't kill the notion that a site boundary exists. This is what RIRs > call a "soft" or "semi-hard" boundary. > > Comments welcome. > > 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 Fri Feb 14 07:42:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFgeQb002220; Fri, 14 Feb 2003 07:42:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EFgeQl002219; Fri, 14 Feb 2003 07:42:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EFgbQb002212 for ; Fri, 14 Feb 2003 07:42:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EFgjVL017704 for ; Fri, 14 Feb 2003 07:42:45 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13419 for ; Fri, 14 Feb 2003 07:42:40 -0800 (PST) Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Fri, 14 Feb 2003 07:42:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5BA04@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLUDwwn1vkX1v7HQc64OmA+ZXw+cQAMDbnw From: "Michel Py" To: "Brian Carpenter" Cc: "Erik Nordmark" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1EFgbQb002213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter wrote: > On balance, I prefer ducking the issue in the draft > we are discussing. If I get a /48 I have 16 bits for > subnet addressing and I'm happy, so why worry about > the acronym SLA? I have not been clear on this but I could not care less about the acronym itself. Killing the acronym is fine, what I think we need to preserve is the concept that there is a boundary there. > (but I still want to see an informational reference to > 3177 to ensure the paper trail is complete). Agree. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 09:34:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EHYiQb004421; Fri, 14 Feb 2003 09:34:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EHYi8C004418; Fri, 14 Feb 2003 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EHYfQb004410 for ; Fri, 14 Feb 2003 09:34:41 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EHYnVL017467 for ; Fri, 14 Feb 2003 09:34:49 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21116 for ; Fri, 14 Feb 2003 09:34:42 -0800 (PST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 14 Feb 2003 09:34:26 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Feb 2003 09:34:42 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 2003 09:34:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 3041 clarification requested Date: Fri, 14 Feb 2003 09:34:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3041 clarification requested Thread-Index: AcLUPsxj4jE2ohSdStODvnn+hB/v0wAEBsTg From: "Richard Draves" To: "Jari Arkko" Cc: "IPV6 WG" X-OriginalArrivalTime: 14 Feb 2003 17:34:41.0672 (UTC) FILETIME=[5B291880:01C2D44F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1EHYfQb004411 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm trying to understand what the following text means and > implies in Section 3.3 of RFC 3041: > > "Note: because multiple temporary addresses are generated from the > same associated randomized interface identifier, there is little > benefit in running DAD on every temporary address. This document > recommends that DAD be run on the first address generated from a > given randomized identifier, but that DAD be skipped on all > subsequent addresses generated from the same randomized interface > identifier." > > Does this refer to multiple addresses when the link has > multiple prefixes? Or when multiple temporary addresses are > generated in sequence? It says "addresses generated from the > given randomized identifier" so one might assume it means the > multiple prefix case. But on the other hand the randomized > identifier is also fed as history to the generation of new > addresses, so it might mean the sequence also. I think it means the multiple addresses when the link has multiple prefixes. > Additionally, I'm wondering how DAD works with RFC 3041. > The scheme appears to rely on the order in which addresses > are generated. On a network with two prefixes A and B two > nodes might not generate and test the addresses in the same > order. For instance, node 1 could test A:: and node 2 > could test B:: first. If the random values collide, > the collision apparently isn't detected and both nodes > proceed to use both A:: and B::. Or did I > miss something? Yes, this is a known bug in the spec. I think you should either run DAD on all your temporary addresses or none of them (if you trust your RNG). > Also, it wasn't clear to me whether link-local addresses are > generated for every new IID or not. If they are, RFC 2462 > rules in Section 5.4 apply and the collision problem may be > solved that way. (Or does it -- where does it say that > "first" in 3041 refers to the link-local address?) You do not generate link-local addresses for the new IIDs. And not site-local either. Just global addresses. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 10:37:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EIbnQb005217; Fri, 14 Feb 2003 10:37:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EIbmfG005216; Fri, 14 Feb 2003 10:37:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EIbjQb005209 for ; Fri, 14 Feb 2003 10:37:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EIbrVL007910 for ; Fri, 14 Feb 2003 10:37:53 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04067 for ; Fri, 14 Feb 2003 11:37:48 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1EIbh9c052594; Fri, 14 Feb 2003 13:37:43 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1EIbgNx050075; Fri, 14 Feb 2003 13:37:42 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1EIbg7M050072; Fri, 14 Feb 2003 13:37:42 -0500 (EST) Date: Fri, 14 Feb 2003 13:37:42 -0500 (EST) From: "Alan E. Beard" To: Dan Lanciani , cc: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses In-Reply-To: <200302140503.AAA12048@ss10.danlan.com> Message-ID: <20030214083213.F43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, Margaret, et al: I have given some thought to the matters raised below. This note will address the questions raised by Dan in his first paragraph; the second paragraph will see a later response. Please be aware that the below should be considered, at its most ambitious, not more than a starting point for group discussion; it is not to be considered a formal proposal. AEB On Fri, 14 Feb 2003, Dan Lanciani wrote: > "Alan E. Beard" wrote: > > |Yes, I think you are probably right in speculating that any technically > |sound mechanism which preserves the virtues of provider independence, > |portability, and stability in configuration of end-user-network devices > |will satisfy the functional requirements of the end-user community. It > |seems to be up to us to architect the mechanism(s). > > Any thoughts on how we might jump start some activity in this area? Over > the years I've tried the bottom-up approach by suggesting some possible > mechanisms, and I've tried the top-down approach by suggesting that we try > to reach consensus on how much overhead we are willing to accept in return > for the solution. The former generally provokes protests that the solution > is too complicated to sketch and the latter usually results in silence. How > can we get some serious discussion going? > [...] > > Dan Lanciani > ddl@danlan.*com > It seems to me that we have in recent weeks seen a shouting-match form of the top-down, how-much-penalty-are-we-willing-to-pay discussion, with one camp asserting loudly that the PA-with-aggregation scheme is strictly necessary for the operation of IPv6, and another group insisting vigorously that any address allocation scheme other than unrestricted PI will be inevitably and utterly fatal to the continued deployment of IPv6. This is roughly equivalent to: do we smother the baby now, or poison it when it reaches puberty? During this debate, most people with any reasonable sense of self-preservation (which immmediately excludes me) were cowering in gator holes, preferring the possibility of a confrontation with an enraged she-gator to the near certainty of an encounter with all the lead flying around out in the sawgrass. In both cases, the magnitude of the postulated adverse effect was deemed to be well beyond the pale, and the discussion subsided to a series of exasperated splutters. There are a number of paths we might explore to encourage some productive discusions. I will suggest below the outline of a sequence which seems to me attractive. First, we may wish to start a top-down discussion with the objective of assembling a list of functional objectives for the address allocation schemes which have been under discussion here. Please note that we have a possible charter problem here - more on that below. Once we have got rough concensus on the functional objectives, we can proceed to a bottom-up approach on mechanisms, and from there to specific proposals for standards, or BCP, or guidance to the registries. Now, we have a scope problem here, which is a result of the wording of the WG charter, and is further complicated by the instructions which came of out the Atlanta meeting. We probably need to consult Margaret before she concludes that we have taken the bit in our teeth (which we have) and are about to put at risk every horse and all the coaches in the staging yard (still undecided). At IETF 55 (Atlanta), floor discussions in the WG meeting indicated that a proposal to limit use of site-local address allocations was contingent, at least in the minds of many of the attendees, on making provision for some form of PI address space which is available to most (preferably _all_) networks. As this last issue did not fall within scope of any of the WG's defined work items, a decision was taken (how's that for passive voice?) to refer the matter to another area (SubIP or OAM, if my memory serves correctly) for consideration. What started in this WG as a discussion peripheral to the issue of restricting use of SL has now devolved into a reconsideration of the fundamental principles and assumptions underlying the address allocation practices for IPv6. This latter discussion is clearly beyond the scope of the current work items for this working group. However, the fundamental issues seem unwilling to fold their tents and steal away quietly into the night. As I read the WG charter, these matters are incontestably within the bounds of the charter, although not subsumed by any extant work item. IMHO, our discussions so far have identified a matter within the scope of the charter which urgently requires a resolution and requires further work toward that end. So far, we have, by dint of quite extraordinary self-restraint (yeah, right), avoided rogue status by confining our activities to disussion of the nature and scope of the perceived problems, rather than commencing formal work upon definition and solution of the problems. However, absent explicit assent from the ADs, formal work of sort suggested above would leave Margaret fully justified in coming 'round with her elephant gun, placing the muzzle squarely between our ears, and discharging as many rounds as she sees fit. (Margaret, I know that you don't carry an elephant gun: the above description is entirely metaphorical, and no imputation of violence attaches to you.) Unlike many judicial bodies, the IETF does not have a compelling tradition of stare decisis: we are not prohibited from revising previous recommendations when changed conditions or new information indicate that the recommendations may no longer comport with reality as we know it. I would suggest that the continuing discussions and controversy over the issue of PI vs PA strongly indicate that additional consideration of IPv6 address allocation practice is urgently needed, if for no other reason than to assure the IETF and the user community that we are recommending technically and operationally feasible models for address allocations. (I will further suggest that the current practices leave that conclusion somewhat in doubt.) It seems to me not unreasonable to ask of Margaret, Rob, Thomas and Erik permission to augment our list of work items with a specific task to review current guidance to the address registries concerning address allocation philosophy and procedure with a view to encouraging user acceptance of IPv6 while maintaining technically sound policies concerning routing overhead. (Yes, that language is ambiguous and imprecise to the point of being downright sloppy - we will need better wording if this is to proceed.) The multi6 WG has a some papers extant which are related to the address allocation practices, one of which is Michel Py's gapi-00 draft. However, there does not seem to be in progress anywhere a comprehensive reconsideration of address allocation practices as related to PA, PI, and routing table burden, nor any current process which explicitly considers end-user expectations concerning IPv6 address allocations and uses permitted thereof. There are, in my view, two extant items in the IPv6 WG charter which subsume the work outlined above, to wit: - Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures. This covers the full discussion and the specific work outlined above. and - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. The specific issues regarding PA, PI, and aggregation will likely afflict IDR and OSPF; further, Multi6 has open work on related issues. In summary, I think that we may have sufficient justification to ask the WG chairs and the ADs to add a specific task to the list of open WG work items: that being a review of current address allocation philosophy and procedures in light of current state of routing protocol specifications and in light of end-user expectations concerning allocation and permitted use of IPv6 addressing. What think ye all? AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 11:51:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EJprQb006686; Fri, 14 Feb 2003 11:51:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EJprnL006685; Fri, 14 Feb 2003 11:51:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EJpnQb006675 for ; Fri, 14 Feb 2003 11:51:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EJpvVK023306 for ; Fri, 14 Feb 2003 11:51:57 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21098 for ; Fri, 14 Feb 2003 12:51:52 -0700 (MST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 14 Feb 2003 11:51:49 -0800 Reply-To: From: "Tony Hain" To: "'Alan E. Beard'" , "'Dan Lanciani'" , Cc: Subject: RE: Enforcing unreachability of site local addresses Date: Fri, 14 Feb 2003 11:51:52 -0800 Message-ID: <03f101c2d462$854c0330$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <20030214083213.F43282-100000@amneris.aebeard.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1EJpnQb006676 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan E. Beard wrote: > ... > What think ye all? We are at an impass. The right outcome is that multi6 defines an approach that works for end sites, while scaling appropriately for the ISP concerns. The reality is that multi6 is off in the weeds rearchitecting the Internet, with no more hope of a useful outcome than the IRTF routing research wg has produced over the last N years. Unfortunately, this puts the ADs in a bind, because they would have a hard time justifing that the IPv6 wg should be tasked with defining an operational plan that an Operations Area wg is already tasked to do. It could be argued that since we are talking about allocations which conform to addr-arch-v3, the IETF is not the right place for the discussion anyway. The sticking point is that if we are talking about space other than 0x001, IANA would need to allocate that, which they are reluctant to do so without IESG buy-in, and since the IESG is in a bind, nothing can happen. Another data point for the discussion. At the NANOG earlier this week, Daniel Golding presented a discussion (http://www.nanog.org/mtg-0302/golding.html) about evolving the peering/inter-provider relationships along the lines where regional exchanges might reasonably become brokers between the regional ISPs & the transit providers. It is exactly that business model where PI approaches like Michele's or mine work well. Right now the IETF is stuck working on the assumption that we have to have a single global DFZ that knows all TE exception cases (even outside the scope of where they make sense), and that both the ISP & the end customers get to have full control of all the knobs. One could argue that it is the IETFs role to define the knobs, get out of the way, then watch and take the lessons learned as input for revising the function of said knobs. While it is frequently attempted, it is rarely wise to legislate operational behavior through the standards process. Despite all that, several people have continued to persue personal drafts with the expectation that eventually an appropriate forum will be found. Michele maintains a site with the active efforts at: http://arneill-py.sacramento.ca.us/ipv6mh/ I have a document that describes the situation and need for PI: http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt and a companion doc which describes one approach to a PI allocation scheme: http://www.tndh.net/~tony/ietf/ipv6piaddressformat-04.txt both of which I plan to refresh before the cutoff. Comments are welcome. 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 14 13:28:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ELSIQb008518; Fri, 14 Feb 2003 13:28:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1ELSI7o008517; Fri, 14 Feb 2003 13:28:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ELSFQb008510 for ; Fri, 14 Feb 2003 13:28:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1ELSNVL002648 for ; Fri, 14 Feb 2003 13:28:23 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (tele2-1-1-dialup-247.freesurf.ch [194.230.196.247]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21158 for ; Fri, 14 Feb 2003 13:28:15 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1ELSihE000488; Fri, 14 Feb 2003 22:28:46 +0100 (CET) Date: Fri, 14 Feb 2003 17:15:52 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Chown , ipng@sunroof.eng.sun.com, randy@psg.com To: "Alan E. Beard" From: Kurt Erik Lindqvist In-Reply-To: <20030213153051.H43282-100000@amneris.aebeard.net> Message-Id: <96BC8BF6-4037-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Most end-user network managers I deal with require these > characteristics > of their public network address allocations: > > 1) uniqueness (sometimes expressed as "autonomy") Wait. This is interesting. From what people here was saying before - I drew the conclusion that end-users wanted non-uniqueness aka site-locals to hide their topology. You are saying something else? > 2) portability I can see that. > 3) stability Do you mean as a derivate of portability or for some other reason? > In many cases, requirement two is driven by a desire to implement > multiple connections to the public networks via more than one service > provider (multihoming). So by portability you mean the ability to have a prefix announcement accepted by multiple providers. > While PI is not an absolute requirement, the present state of our > The above properties of a prefix is not the same as PI, as well as PI properties are not the same as above. For both IPv4 and IPv6. > technology and standards (for v6 as well as v4) force us to PI as the > only > implemented mechanism which satisfies the functional requirements > enumerated above. If we can develop and write into the standards some (Someone could say NAT and SL but I am glad you didn't) Agreed. > For those end-user-network managers who are aware of the details of the > NREN allocations, this situation provokes pure, incandescent fury: the > academic entities are seen as having been granted special (and grossly > preferential) treatment, while the commercial (as distinguished from > service-provider) networks are subject to callous indifference and > excluded thereby from direct access to stable network address > allocations. > We can't even claim "separate but equal" for this state of affairs, and > the universal principle of Brown V. Board of Education still holds, > even > for networks. [For those not familiar with recent US history, send me > mail > directly for a brief explanation of the above reference. AEB] I am not familiar with the above, but I generally tend to agree that NREN and other networks are far different. For good and bad. > Most of the end-user-network managers among my clients now multihome, > and > will continue to require multihomed service in future. In every case > where the user's network is multihomed, the multiple independent > connections are seen as crucial for maintenance of high availability of I find this funny. A number of studies have shown that if this is what you are after, multihoming and BGP is the wrong way to go - but never mind. > the client's services to the public networks; and high availability is > considered an absolute requirement for survival of the business. In > some > cases there are regulatory requirements which can result in civil or > administrative sanctions (including, in the worst event, loss of > operating > licenses) if the services should be found unavailable for significant > periods of time. Yes, it is possible, at least in theory, for > commercial > service providers to sustain the required level of availability, but > most > of my clients have found, much to their distress, that the US ISPs are > almost uniformly incapable of doing so in practice. In almost every > case, > the administrative managers for these user networks are simply and > flatly > unwilling to put their businesses at the mercy of a single ISP. This worries me but is more a topic of Nanog, or my planned presentation at the Barcelona RIPE rather than IPng. > Based on conversations with my clients, I cannot find it within the > scope > of my imagination (or, for that matter, of theirs) that these networks > will give up the mutilhoming requirement at any time within the > foreseeable future. Hmm. So if someone where to write up a draft on how to do resilient routing, with different alternatives and pros and cons, could you take this to your customers? Randy, is this something to add to the Barcelona topics? I think I have some slides to start this off....(now all we need is a logo and we have a project) > Home networks may be another matter, but I would give my eyeteeth to > get a > stable, portable (and, thereby, multihome-capable) IPv6 allocation for > _my_ home network, as that network also supports supports my office and Notice that this comes at a price. You and me are willing to pay for this, but how many are? > suspect that we will find increasing use of "home" networks for > business > activity, and increasing demand for stability of network locator Sure, but are you willing to pay for it? > can't multihome. Based on experience with my client base, I cannot > agree > with the postulate that many networks will not find lack of multihome > support a barrier to implementation of v6. I agree. Your client base seems to be exactly the target group. However, they also seems to be willing to pay for the service, as otherwise they will suffer financial loss that is higher than a days salary (if you can't log in from your home network). > The current speculation about "what the users _really_ need" (as > distinguished from what they _say_ they need) smacks to me of "all > networks are equal, but some are more equal than others" (with > apologies > to _Animal Farm_). It seems to me that we have some technical > problems Agreed. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 14 14:04:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EM4cQb008701; Fri, 14 Feb 2003 14:04:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1EM4cVw008700; Fri, 14 Feb 2003 14:04:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1EM4ZQb008693 for ; Fri, 14 Feb 2003 14:04:35 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1EM4hVL013320 for ; Fri, 14 Feb 2003 14:04:43 -0800 (PST) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13943 for ; Fri, 14 Feb 2003 14:04:38 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Fri, 14 Feb 2003 14:04:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54C00@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcLUYvfJTqTj3HU0T3KZbukFmnDfnQADm/yg From: "Michel Py" To: "Tony Hain" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1EM4ZQb008694 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony Hain wrote: > We are at an impass. Indeed. > this puts the ADs in a bind, because they would have a hard > time justifing that the IPv6 wg should be tasked with defining > an operational plan that an Operations Area wg is already > tasked to do. Yep. Some will remember that in an attempt to shake things up, a year or two ago I tried to bypass multi6 and sent my text to ngtrans. The result was the addition of text in the ngtrans charter that specifically labeled multihoming solutions as non-goals that would not be looked at by the WG. We're deadlocked. > It is exactly that business model where PI approaches like > Michele's or mine work well. To set the record straight, Tony's drafts have been one of the major sources inspiring GAPI in the early stages. One of the interim releases of MHAP actually used Tony's scheme before GAPI was written. > I have a document that describes the situation and need for PI: > http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt I never bothered writing something like this as Tony's text is also valid for GAPI for the most part. Read it. 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 14 18:00:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1F200Qb009665; Fri, 14 Feb 2003 18:00:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1F200en009664; Fri, 14 Feb 2003 18:00:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1F1xuQb009657 for ; Fri, 14 Feb 2003 17:59:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1F204VK018235 for ; Fri, 14 Feb 2003 18:00:05 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06132 for ; Fri, 14 Feb 2003 18:59:59 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1F1xN9c053240; Fri, 14 Feb 2003 20:59:23 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1F1xNNx050647; Fri, 14 Feb 2003 20:59:23 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1F1xLPb050644; Fri, 14 Feb 2003 20:59:22 -0500 (EST) Date: Fri, 14 Feb 2003 20:59:21 -0500 (EST) From: "Alan E. Beard" To: Kurt Erik Lindqvist cc: Tim Chown , , Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <96BC8BF6-4037-11D7-874A-000393AB1404@kurtis.pp.se> Message-ID: <20030214175244.P43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurtis: Thanks for your thoughtful response. I'll reply to your queries inline. AEB On Fri, 14 Feb 2003, Kurt Erik Lindqvist wrote: > > Most end-user network managers I deal with require these > > characteristics > > of their public network address allocations: > > > > 1) uniqueness (sometimes expressed as "autonomy") > > Wait. This is interesting. From what people here was saying before - I > drew the conclusion that end-users wanted non-uniqueness aka > site-locals to hide their topology. You are saying something else? > Please note the keyword "public" in the statement above. This applies (in the cases of most of my clients) to address spaces which are advertised to the public networks (AKA The Internet). Now, in answer to your implied question about addressing for private (internal) networks: Given the choice, most (in fact, nearly all) of my clients would prefer to run their internal networks on registered, unique, globally routable address space; this greatly simplifies the task of providing access to resources on the public network, and of providing access from the public networks to resouces which the external customers of the business desire to use, usually with the result of generating revenue for the business. Furthermore, the use of unique, globally routable address space vastly simplifies the task of establishing connections to networks operated by business partners (eg, vendors and larger customers), whether via the public network or over private links. However, my clients are wholly unwilling to run even the slightest risk of a forced renumbering on their internal networks. Full stop. No exceptions, and no equivocations. If unique and stable globally routable space is not available for use in their internal networks, my clients see non-unique, globally non-routable space, coupled with NAT, as a feasible (but not desirable) alternative: at least they have a reasonable expectation that such addressing will be stable, and that a forced renumbering is unlikely. For IPv6, the site local space meets the requirement for internal networks of address stability. That the SL (or, for IPv4, PNN) space is globally non-routable mitigates somewhat the inconvenience of maintaining NAT: if you use application-level gateways in addition to NAT, the ACLs can be less complex (although not less carefully crafted) than otherwise. With such an implementation, it becomes relatively straightforward to obscure the details of internal network structure (at least from the standpoint of the public networks) since neither the prefix nor the internal structure is advertised beyond the local environment. And yes, these clients do realise that the above steps are not alone sufficient to forestall intrusion or other malicious acts. > > 2) portability > > I can see that. > > > 3) stability > > Do you mean as a derivate of portability or for some other reason? > No. The stability requirement is quite independent of portability. My clients desire to avoid renumbering at any cost short of summary hanging; where it is not posiible to avoid renumbering, they wish to renumber as few systems as possible, and they would much rather change a static translation mapping than reconfigure a host. Where these clients are forced into renumbering (say, when they have to change ISPs as a result of poor service), they are vastly dissatisfied and profoundly resentful. For public network address spaces, portability is an aid in achieving stability, but hosts will have stable numbering even if the public network addressing is neither portable or stable. I think that the prevailing opinion in this WG has been that the situation described above (at least, the worst-case configuration) is not desirable. > > In many cases, requirement two is driven by a desire to implement > > multiple connections to the public networks via more than one service > > provider (multihoming). > > > So by portability you mean the ability to have a prefix announcement > accepted by multiple providers. > No, although that is one element. The specific meaning attached to "portable" by most of my clients is this: "when I discontinue service with any ISP (actually, Internet Access Provider, as most of my clients maintain the services - that is, hosts and applications, including DNS and SMTP - inhouse), the addressing of my hosts as seen from the public networks remains with me. Furthermore, I can advertise the (usually native) addresses of my hosts via any combination of access providers willing to carry the traffic and provide transit routing." > > While PI is not an absolute requirement, the present state of our > > > > The above properties of a prefix is not the same as PI, as well as PI > properties are not the same as above. For both IPv4 and IPv6. > > > technology and standards (for v6 as well as v4) force us to PI as the > > only > > implemented mechanism which satisfies the functional requirements > > enumerated above. If we can develop and write into the standards some > > (Someone could say NAT and SL but I am glad you didn't) Agreed. > Well, NAT and SL will work (even if administratively proscribed), although at undesirably high administrative cost, if no better solution is available. However, my clients won't be content with NAT and SL, even if they see it as the least distasteful option open to them. > > For those end-user-network managers who are aware of the details of the > > NREN allocations, this situation provokes pure, incandescent fury: the > > academic entities are seen as having been granted special (and grossly > > preferential) treatment, while the commercial (as distinguished from > > service-provider) networks are subject to callous indifference and > > excluded thereby from direct access to stable network address > > allocations. > > We can't even claim "separate but equal" for this state of affairs, and > > the universal principle of Brown V. Board of Education still holds, > > even > > for networks. [For those not familiar with recent US history, send me > > mail > > directly for a brief explanation of the above reference. AEB] > > I am not familiar with the above, but I generally tend to agree that > NREN and other networks are far different. For good and bad. > I agree that NREN networks differ from other networks, but it does not follow that other networks should thereby be forced to discriminatory treatment while NREN networks obtain top-quality service. (BTW, Brown v. Board is a 1950s US Supreme Court ruling which held that, in the provision of services - in this case, public education - separate facilities or service models for different groups are inherently unequal. Furthermore, the Court held that, in this context, unequal == discriminatory. This is considered a landmark ruling in the area of civil rights law.) > > Most of the end-user-network managers among my clients now multihome, > > and > > will continue to require multihomed service in future. In every case > > where the user's network is multihomed, the multiple independent > > connections are seen as crucial for maintenance of high availability of > > I find this funny. A number of studies have shown that if this is what > you are after, multihoming and BGP is the wrong way to go - but never > mind. > Your comment may be true, but my clients are nonetheless unwilling to risk the possibility of an extended network outage on a single ISP (while not frequent, these events are far from unprecedented) rendering their online customer-support environment unavailable for several hours, much less for a day. Shorter outages (on the order of minutes in the single digits) are tolerated, provided that such outages are infrequent. > > the client's services to the public networks; and high availability is > > considered an absolute requirement for survival of the business. In > > some > > cases there are regulatory requirements which can result in civil or > > administrative sanctions (including, in the worst event, loss of > > operating > > licenses) if the services should be found unavailable for significant > > periods of time. Yes, it is possible, at least in theory, for > > commercial > > service providers to sustain the required level of availability, but > > most > > of my clients have found, much to their distress, that the US ISPs are > > almost uniformly incapable of doing so in practice. In almost every > > case, > > the administrative managers for these user networks are simply and > > flatly > > unwilling to put their businesses at the mercy of a single ISP. > > This worries me but is more a topic of Nanog, or my planned > presentation at the Barcelona RIPE rather than IPng. > This should worry all of us if we are determined to require PA as the default allocation model for IPv6. And I will suggest that this is properly a topic for the IPv6 working group: have a look at the charter. > > Based on conversations with my clients, I cannot find it within the > > scope > > of my imagination (or, for that matter, of theirs) that these networks > > will give up the mutilhoming requirement at any time within the > > foreseeable future. > > Hmm. So if someone where to write up a draft on how to do resilient > routing, with different alternatives and pros and cons, could you take > this to your customers? Randy, is this something to add to the > Barcelona topics? I think I have some slides to start this off....(now > all we need is a logo and we have a project) > Yes. However, I must caution you that resilient routing alone will not resolve the objections of most of my clients to IPv6 as presently managed; it merely removes one item from the washing bill. > > Home networks may be another matter, but I would give my eyeteeth to > > get a > > stable, portable (and, thereby, multihome-capable) IPv6 allocation for > > _my_ home network, as that network also supports supports my office and > > Notice that this comes at a price. You and me are willing to pay for > this, but how many are? > > > suspect that we will find increasing use of "home" networks for > > business > > activity, and increasing demand for stability of network locator > > Sure, but are you willing to pay for it? > Yup. But willingness to pay is moot if the service can't be had due to administrative fiat. (This comment is in the business-network context.) > > can't multihome. Based on experience with my client base, I cannot > > agree > > with the postulate that many networks will not find lack of multihome > > support a barrier to implementation of v6. > > I agree. Your client base seems to be exactly the target group. > However, they also seems to be willing to pay for the service, as > otherwise they will suffer financial loss that is higher than a days > salary (if you can't log in from your home network). > I suggest further that these issues extend far beyond my client base; in fact, to most businesses that rely in whole or in part on online systems (those accessible from the public networks) for all or a substantial part of their revenue. The number of such busineses is growing, and I would prefer that it continue to do so. Under the current IPv6 allocation practices, most of my clients can't get PI space, even if they were willing to pay unlimited fees, since most of the groups are not multi-national is scope. (In many cases, these businesses hold state or national charters which explicitly forbid interoperation with foreign businesses of the same type. Please note that foreign transactions are not prohibited, but sharing of operational facilities - including networks - _is_ expressly forbidden. At a minimum, a Chinese wall - i.e. firewalls and separate routing domains - is required to satisfy the audit requirements.) > > The current speculation about "what the users _really_ need" (as > > distinguished from what they _say_ they need) smacks to me of "all > > networks are equal, but some are more equal than others" (with > > apologies > > to _Animal Farm_). It seems to me that we have some technical > > problems > > Agreed. > > - kurtis - > > I hope the above has clarified (or at least disambiguated) some of my statements in the original note. Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 03:37:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FBbAQb010674; Sat, 15 Feb 2003 03:37:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FBb9JS010673; Sat, 15 Feb 2003 03:37:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FBb5Qb010666 for ; Sat, 15 Feb 2003 03:37:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FBbFVL000227 for ; Sat, 15 Feb 2003 03:37:15 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21491 for ; Sat, 15 Feb 2003 03:37:09 -0800 (PST) Received: from localhost (unknown [3ffe:501:4819:2000:5c96:c497:79b6:14cd]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0580315214; Sat, 15 Feb 2003 20:37:16 +0900 (JST) Date: Sat, 15 Feb 2003 20:37:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: "IPV6 WG" Subject: Re: RFC 3041 clarification requested In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 14 Feb 2003 09:34:41 -0800, >>>>> "Richard Draves" said: >> Also, it wasn't clear to me whether link-local addresses are >> generated for every new IID or not. If they are, RFC 2462 >> rules in Section 5.4 apply and the collision problem may be >> solved that way. (Or does it -- where does it say that >> "first" in 3041 refers to the link-local address?) > You do not generate link-local addresses for the new IIDs. And not > site-local either. Just global addresses. Why not for site-local addresses? 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 15 05:27:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FDR1Qb010973; Sat, 15 Feb 2003 05:27:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FDR1cr010972; Sat, 15 Feb 2003 05:27:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FDQwQb010965 for ; Sat, 15 Feb 2003 05:26:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FDR7VL011560 for ; Sat, 15 Feb 2003 05:27:07 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28020 for ; Sat, 15 Feb 2003 06:27:01 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA19095 for ; Sat, 15 Feb 2003 13:27:00 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1FDQxU3008495 for ; Sat, 15 Feb 2003 13:26:59 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1FDQwM24612 for ipng@sunroof.eng.sun.com; Sat, 15 Feb 2003 13:26:58 GMT Date: Sat, 15 Feb 2003 13:26:58 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Message-ID: <20030215132658.GB24509@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <96BC8BF6-4037-11D7-874A-000393AB1404@kurtis.pp.se> <20030214175244.P43282-100000@amneris.aebeard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030214175244.P43282-100000@amneris.aebeard.net> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Feb 14, 2003 at 08:59:21PM -0500, Alan E. Beard wrote: > > > I agree that NREN networks differ from other networks, but it does not > follow that other networks should thereby be forced to discriminatory > treatment while NREN networks obtain top-quality service. (BTW, Brown v. > Board is a 1950s US Supreme Court ruling which held that, in the provision > of services - in this case, public education - separate facilities or > service models for different groups are inherently unequal. Furthermore, > the Court held that, in this context, unequal == discriminatory. This is > considered a landmark ruling in the area of civil rights law.) Alan, I note a second reference to this... You seem to have an "issue" with publicly funded research/education networks, which I don't quite understand. There are advantages and disadvantages with being attached to an NREN. There are quite strict AUPs that (should) prevent such networks being used for commercial purposes (which would be unfair competition with commercial providers). My original point was that there is a large (but very much minority) user and system base in the educational networks, where aggregation and (site or enterprise) multihoming is very rare (one of the disadvantages :) Perhaps universities in the future will be more keen to be multi-homed, but enterprise level multihoming is rare in this context. Universities are not forced to use NREN infrastructure, although it would not generally make financial or technical sense to go elsewhere. Tim > > > the client's services to the public networks; and high availability is > > > considered an absolute requirement for survival of the business. In > > > some > > > cases there are regulatory requirements which can result in civil or > > > administrative sanctions (including, in the worst event, loss of > > > operating > > > licenses) if the services should be found unavailable for significant > > > periods of time. Yes, it is possible, at least in theory, for > > > commercial > > > service providers to sustain the required level of availability, but > > > most > > > of my clients have found, much to their distress, that the US ISPs are > > > almost uniformly incapable of doing so in practice. In almost every > > > case, > > > the administrative managers for these user networks are simply and > > > flatly > > > unwilling to put their businesses at the mercy of a single ISP. > > > > This worries me but is more a topic of Nanog, or my planned > > presentation at the Barcelona RIPE rather than IPng. > > > This should worry all of us if we are determined to require PA as the > default allocation model for IPv6. And I will suggest that this is > properly a topic for the IPv6 working group: have a look at the charter. > > > > Based on conversations with my clients, I cannot find it within the > > > scope > > > of my imagination (or, for that matter, of theirs) that these networks > > > will give up the mutilhoming requirement at any time within the > > > foreseeable future. > > > > Hmm. So if someone where to write up a draft on how to do resilient > > routing, with different alternatives and pros and cons, could you take > > this to your customers? Randy, is this something to add to the > > Barcelona topics? I think I have some slides to start this off....(now > > all we need is a logo and we have a project) > > > Yes. However, I must caution you that resilient routing alone will not > resolve the objections of most of my clients to IPv6 as presently managed; > it merely removes one item from the washing bill. > > > > Home networks may be another matter, but I would give my eyeteeth to > > > get a > > > stable, portable (and, thereby, multihome-capable) IPv6 allocation for > > > _my_ home network, as that network also supports supports my office and > > > > Notice that this comes at a price. You and me are willing to pay for > > this, but how many are? > > > > > suspect that we will find increasing use of "home" networks for > > > business > > > activity, and increasing demand for stability of network locator > > > > Sure, but are you willing to pay for it? > > > Yup. But willingness to pay is moot if the service can't be had due to > administrative fiat. (This comment is in the business-network context.) > > > > can't multihome. Based on experience with my client base, I cannot > > > agree > > > with the postulate that many networks will not find lack of multihome > > > support a barrier to implementation of v6. > > > > I agree. Your client base seems to be exactly the target group. > > However, they also seems to be willing to pay for the service, as > > otherwise they will suffer financial loss that is higher than a days > > salary (if you can't log in from your home network). > > > I suggest further that these issues extend far beyond my client base; in > fact, to most businesses that rely in whole or in part on online systems > (those accessible from the public networks) for all or a substantial part > of their revenue. The number of such busineses is growing, and I would > prefer that it continue to do so. Under the current IPv6 allocation > practices, most of my clients can't get PI space, even if they were > willing to pay unlimited fees, since most of the groups are not > multi-national is scope. (In many cases, these businesses hold state or > national charters which explicitly forbid interoperation with foreign > businesses of the same type. Please note that foreign transactions are > not prohibited, but sharing of operational facilities - including networks > - _is_ expressly forbidden. At a minimum, a Chinese wall - i.e. firewalls > and separate routing domains - is required to satisfy the audit > requirements.) > > > > The current speculation about "what the users _really_ need" (as > > > distinguished from what they _say_ they need) smacks to me of "all > > > networks are equal, but some are more equal than others" (with > > > apologies > > > to _Animal Farm_). It seems to me that we have some technical > > > problems > > > > Agreed. > > > > - kurtis - > > > > > > I hope the above has clarified (or at least disambiguated) some of my > statements in the original note. > > Regards, > > AEB > > -- > Alan E. Beard > AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 > 863.815.2529 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 15 09:29:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FHTWQb011422; Sat, 15 Feb 2003 09:29:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FHTV08011419; Sat, 15 Feb 2003 09:29:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FHTQQb011410 for ; Sat, 15 Feb 2003 09:29:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FHTZVK026199 for ; Sat, 15 Feb 2003 09:29:35 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24665 for ; Sat, 15 Feb 2003 10:29:29 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1FHSv9c057129; Sat, 15 Feb 2003 12:28:57 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1FHSvNx054666; Sat, 15 Feb 2003 12:28:57 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1FHSvu8054663; Sat, 15 Feb 2003 12:28:57 -0500 (EST) Date: Sat, 15 Feb 2003 12:28:56 -0500 (EST) From: "Alan E. Beard" To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <20030215132658.GB24509@login.ecs.soton.ac.uk> Message-ID: <20030215121250.B43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim: Please don't misunderstand my intent here: I don't have a problem with the NREN networks, or with the top-quality treatment afforded them in the matter of address allocations. These networks clearly deserve, and should have, the best available quality of service in matters related to address allocations. Additionally, the views expressed in my note don't originate with me; rather, my note contained a precis of the views expressed to me (sometimes in language of markedly purple and blue character) by some of my clients. The objections cited are not to the treatment afforded to the NREN networks, but to the decidedly discriminatory treatment afforded to end-user commercial (as distinguished from service-provider) networks. I offer my profound and abject apologies to the NREN networks; I deeply regret any imputation of dog-in-the-manger attitude which might have arisen from any reading of my statement; such was certainly not my intent. Thank you for raising this matter, and for offering an opportunity to correct any mistaken impression which might have arisen from my note. Regards, AEB On Sat, 15 Feb 2003, Tim Chown wrote: > On Fri, Feb 14, 2003 at 08:59:21PM -0500, Alan E. Beard wrote: > > > > > I agree that NREN networks differ from other networks, but it does not > > follow that other networks should thereby be forced to discriminatory > > treatment while NREN networks obtain top-quality service. (BTW, Brown v. > > Board is a 1950s US Supreme Court ruling which held that, in the provision > > of services - in this case, public education - separate facilities or > > service models for different groups are inherently unequal. Furthermore, > > the Court held that, in this context, unequal == discriminatory. This is > > considered a landmark ruling in the area of civil rights law.) > > Alan, > > I note a second reference to this... > > You seem to have an "issue" with publicly funded research/education > networks, which I don't quite understand. There are advantages and > disadvantages with being attached to an NREN. There are quite strict > AUPs that (should) prevent such networks being used for commercial > purposes (which would be unfair competition with commercial providers). > > My original point was that there is a large (but very much minority) user > and system base in the educational networks, where aggregation and (site > or enterprise) multihoming is very rare (one of the disadvantages :) > Perhaps universities in the future will be more keen to be multi-homed, > but enterprise level multihoming is rare in this context. > > Universities are not forced to use NREN infrastructure, although it would > not generally make financial or technical sense to go elsewhere. > > Tim > -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 10:23:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FINbQb011613; Sat, 15 Feb 2003 10:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FINbI8011612; Sat, 15 Feb 2003 10:23:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FINYQb011605 for ; Sat, 15 Feb 2003 10:23:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FINhVL015606 for ; Sat, 15 Feb 2003 10:23:43 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17798 for ; Sat, 15 Feb 2003 10:23:38 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA24329 for ; Sat, 15 Feb 2003 18:23:36 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1FINXU3008513 for ; Sat, 15 Feb 2003 18:23:33 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1FINXx27531 for ipng@sunroof.eng.sun.com; Sat, 15 Feb 2003 18:23:33 GMT Date: Sat, 15 Feb 2003 18:23:33 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses Message-ID: <20030215182333.GG27053@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030215132658.GB24509@login.ecs.soton.ac.uk> <20030215121250.B43282-100000@amneris.aebeard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030215121250.B43282-100000@amneris.aebeard.net> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alan, Hopefully in IPv6 the address allocation policies can be more equitable for all. A large university or a small commercial enterprise can both get a /48. No need to fill out bundles of paperwork to get more than a /28 for your IPv4 leased line... :) (The paperwork comes when you want your second /48, but that should be a while off!) At the ISP level, it seems SubTLA allocation policies are quite open at the moment (more so than a year ago), and this is reflected in the recent (relative) explosion in SubTLA allocations made. Or do you still perceive soemthing different happening? [As an aside, there are many colleges in the UK with a /28 and NAT, but that's another story...] Cheers, Tim On Sat, Feb 15, 2003 at 12:28:56PM -0500, Alan E. Beard wrote: > Tim: > > Please don't misunderstand my intent here: I don't have a problem with > the NREN networks, or with the top-quality treatment afforded them in the > matter of address allocations. These networks clearly deserve, and should > have, the best available quality of service in matters related to address > allocations. > > Additionally, the views expressed in my note don't originate with me; > rather, my note contained a precis of the views expressed to me (sometimes > in language of markedly purple and blue character) by some of my clients. > The objections cited are not to the treatment afforded to the NREN > networks, but to the decidedly discriminatory treatment afforded to > end-user commercial (as distinguished from service-provider) networks. > > I offer my profound and abject apologies to the NREN networks; I deeply > regret any imputation of dog-in-the-manger attitude which might have > arisen from any reading of my statement; such was certainly not my intent. > > Thank you for raising this matter, and for offering an opportunity to > correct any mistaken impression which might have arisen from my note. > > Regards, > > AEB > > On Sat, 15 Feb 2003, Tim Chown wrote: > > > On Fri, Feb 14, 2003 at 08:59:21PM -0500, Alan E. Beard wrote: > > > > > > > I agree that NREN networks differ from other networks, but it does not > > > follow that other networks should thereby be forced to discriminatory > > > treatment while NREN networks obtain top-quality service. (BTW, Brown v. > > > Board is a 1950s US Supreme Court ruling which held that, in the provision > > > of services - in this case, public education - separate facilities or > > > service models for different groups are inherently unequal. Furthermore, > > > the Court held that, in this context, unequal == discriminatory. This is > > > considered a landmark ruling in the area of civil rights law.) > > > > Alan, > > > > I note a second reference to this... > > > > You seem to have an "issue" with publicly funded research/education > > networks, which I don't quite understand. There are advantages and > > disadvantages with being attached to an NREN. There are quite strict > > AUPs that (should) prevent such networks being used for commercial > > purposes (which would be unfair competition with commercial providers). > > > > My original point was that there is a large (but very much minority) user > > and system base in the educational networks, where aggregation and (site > > or enterprise) multihoming is very rare (one of the disadvantages :) > > Perhaps universities in the future will be more keen to be multi-homed, > > but enterprise level multihoming is rare in this context. > > > > Universities are not forced to use NREN infrastructure, although it would > > not generally make financial or technical sense to go elsewhere. > > > > Tim > > > > -- > Alan E. Beard > AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 > 863.815.2529 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 15 10:25:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FIPbQb011630; Sat, 15 Feb 2003 10:25:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FIPa3n011629; Sat, 15 Feb 2003 10:25:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FIPXQb011622 for ; Sat, 15 Feb 2003 10:25:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FIPgVK002511 for ; Sat, 15 Feb 2003 10:25:42 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24560 for ; Sat, 15 Feb 2003 11:25:36 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1FIPC9c057229; Sat, 15 Feb 2003 13:25:12 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1FIPBNx054742; Sat, 15 Feb 2003 13:25:11 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1FIPBmj054739; Sat, 15 Feb 2003 13:25:11 -0500 (EST) Date: Sat, 15 Feb 2003 13:25:11 -0500 (EST) From: "Alan E. Beard" To: Tony Hain , Michel Py , "Fred L. Templin" cc: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C00@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030215075112.O43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks: OK. In the past several days, I have: read Tony's ipv6ipaddressusage-04 draft read Michel's gapi-00 draft reviewed the site-local use discussion in the IPv6 WG read the Multi6 charter read the Multi6 requirements draft re-read RFC 2373 and RFC 2374 re-read the addr-arch-v3 draft re-read the ipv6-prefix-delegation-requirement-00 draft re-read the ipv6-ipaddressassign-06 draft read Iljitch van Beijnum's multi6-isp-int-aggr-00 draft read Michel's Multi Homing Aliasing Protocol draft I went back and ploughed through my archive of ngtrans mail. At one point I thought I had got myself into a configuration which features a permanently recirculating digestive system. 8-/ There is much high-quality work in the documents and discussions cited above. Each of the drafts proposes a solution to a specific problem or elememt of a problem, or, in some cases, proposes tools to handle some of the effects of the percieved problem; the proposals have substantial technical merit, and all deserve full and careful consideration. After working through the reading listed above, a disturbing notion began niggling around in the back of my brain (what little there is of it). More below. On Fri, 14 Feb 2003, Michel Py wrote: > > Tony Hain wrote: > > We are at an impass. > > Indeed. > > No wonder we're at an impasse: we have a blind-men-and-the-elephant problem here! Each of the discussions and drafts cited above defines a problem, and, in most cases, proposes a solution for that problem or a tool to help constrain the problem space. As I read the documents and discussion logs, all the problems described converge on a common underlying root issue. In effect, each group or author has siezed upon one aspect of the root issue (one the trunk; another an ear, the third a leg; ...) and then described a possible solution for that aspect of the issue. I suggest that we might be able to make more progress if we directly address the underlying issue. This is not to sugggest that the problems severally described in the citations above will automagically disappear once the root issue is resolved; however, I think that most (probably all) of the discrete problems will then become much easier to solve. The common, underlying issue, as I see it, is: The use of PA space in end-user networks has the effect of imposing upon those networks functional burdens and restrictions in multiple areas which the managers of commercial end-user networks may be unwilling to tolerate. In consequence, we may need to reconsider our current address allocation practice, which relies principally on the PA model, in light of current user expectations, current state of the routing protocols and standards, and anticipated developments in routing and switching code. Given the present state of our technologies, any discussion of a change in address allocation models will inevitably entail extensive consideration of scalability and routing-table-size issues, along with aggregation and related matters. > > this puts the ADs in a bind, because they would have a hard > > time justifing that the IPv6 wg should be tasked with defining > > an operational plan that an Operations Area wg is already > > tasked to do. > > Yep. Some will remember that in an attempt to shake things up, a year or > two ago I tried to bypass multi6 and sent my text to ngtrans. The result > was the addition of text in the ngtrans charter that specifically > labeled multihoming solutions as non-goals that would not be looked at > by the WG. We're deadlocked. > I think we may be able to break the deadlock and, for lagniappe, get the ADs out of their bind (provided they really are so constrained) by proposing to deal directly with the root issue rather than continuing to nibble away at the leaves. As I read the charters and tasks lists, there are mutiple tasks extant which treat some aspect of the PA functional restrictions and burdens on end-user networks, but no task which coordinates activities across the multiple working groups on the issues arising from PA in end-user networks. Additionally, there is no task open which deals directly with the user-community concerns over the functional burdens imposed on end-user networks by forced use of PA. > > > It is exactly that business model where PI approaches like > > Michele's or mine work well. > > To set the record straight, Tony's drafts have been one of the major > sources inspiring GAPI in the early stages. One of the interim releases > of MHAP actually used Tony's scheme before GAPI was written. > The drafts cited above present tools and practices which may very well be a part of the solution set for the underlying issue, in adddition to providing specific solutions in particular functional areas. > > > I have a document that describes the situation and need for PI: > > http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt > > I never bothered writing something like this as Tony's text is also > valid for GAPI for the most part. Read it. > > Michel. > > I have read Tony's draft, and it does contain a very good statement of specific needs which are amenable to solution by use of PI. This is very fine work indeed. Now, I intend to make a specific proposal on next steps below, and then pose these questions: 1) Should we ask for something akin to the steps proposed below? 2) Is there another approach which will work at least as well, and, if so, what is it? 3) Are we approaching this matter hind-end-foremost? or 4) I am the functional equivalent of a skunk with his head stuck in a tin can? (Alternately expressed: is this proposal fundamentally wrong-headed, and should we abandon it in favor or more productive discussions?) Here is a starting point for discussion of next steps. We may wish to: 1) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6 task list a work item which directs the WG to coordinate and support extant activities in other WGs which deal with issues surrounding use of PA and PI address spaces in, or at the boundaries of, end-user networks. (Note: this language will need to be clarified. Suggestions welcome.) This is incontestably within the working group charter, as indicated by this charge in the charter statement: - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. 2) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6 task list a work item which directs the WG to review and, if needed, recommend revisions to the current IPv6 unicast address allocation practice in light of current user expectations, current state of the routing protocols and standards, and anticipated developments in routing and switching code. Here again, this is incontestably within the scope of the WG charter, as indicated by this charge in the charter statement: - Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures. OK, let the gates down - I'm eager for comments. Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 11:10:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FJAwQb012062; Sat, 15 Feb 2003 11:10:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FJAvan012061; Sat, 15 Feb 2003 11:10:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FJAsQb012054 for ; Sat, 15 Feb 2003 11:10:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FJB3VL021739 for ; Sat, 15 Feb 2003 11:11:04 -0800 (PST) Received: from vador.skynet.be (vador.skynet.be [195.238.3.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17181 for ; Sat, 15 Feb 2003 12:10:57 -0700 (MST) Received: from tsn (225.157-201-80.adsl.skynet.be [80.201.157.225]) by vador.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with ESMTP id h1FJApPT014739 for ; Sat, 15 Feb 2003 20:10:51 +0100 (MET) (envelope-from ) Message-Id: <200302151910.h1FJApPT014739@vador.skynet.be> From: "Mario Goebbels" To: Subject: RE: Flexible address policy on 2000::/3? Date: Sat, 15 Feb 2003 20:10:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4523 In-Reply-To: <3E4CF6C5.16E4E23@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Does this imply that the 13bit TLA of the initial > addressing scheme is > > scrapped too? > > Yes. See http://www.ripe.net/ripe/docs/ipv6policy.html So the addressing structure/hierarchy is completely in the hands of the IANA and subsequent registries? Is this even a good idea regarding the routing (tables)? Thanks for any info. -mg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 15:37:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FNbOQb012636; Sat, 15 Feb 2003 15:37:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1FNbO13012635; Sat, 15 Feb 2003 15:37:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1FNbLQb012628 for ; Sat, 15 Feb 2003 15:37:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1FNbTVL025819 for ; Sat, 15 Feb 2003 15:37:30 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25226 for ; Sat, 15 Feb 2003 16:37:23 -0700 (MST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1FNbMaj031571; Sun, 16 Feb 2003 01:37:23 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1FNbHBf031570; Sun, 16 Feb 2003 01:37:17 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Reason for the explicit link-layer address options in ND? From: Mika Liljeberg To: James Kempf Cc: "Bound, Jim" , Pekka Nikander , IPV6 WG , SEND WG In-Reply-To: <00e301c2d2b9$d91c2bc0$846015ac@T23KEMPF> References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED2@tayexc13.americas.cpqcorp.net> <00e301c2d2b9$d91c2bc0$846015ac@T23KEMPF> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045352236.27666.94.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Feb 2003 01:37:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2003-02-12 at 19:11, James Kempf wrote: > But isn't there a simple attack in which the attacker sends an NA message out > with the victim's link layer address in the option but its own address on the > frame? Naturally, if the link layer allows the attacker to send out frames under > a false address, it could fully spoof the victim as well. Cache poisoning. It seems to me that this could be made much harder with a very slight change to the ND specification: store the Override bit into the cache entry, and only allow an advertisment with Override=1 to overwrite an entry with stored_Override=0, otherwise transition the entry to STALE as with Override=0. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 15 20:57:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1G4vLQb013296; Sat, 15 Feb 2003 20:57:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1G4vL49013295; Sat, 15 Feb 2003 20:57:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1G4vIQb013288 for ; Sat, 15 Feb 2003 20:57:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1G4vRVL001234 for ; Sat, 15 Feb 2003 20:57: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 nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28532 for ; Sat, 15 Feb 2003 20:57:22 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Sat, 15 Feb 2003 20:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54C08@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcLVH5gvhpd/SQcwSlOR/Sbb58REowAUmI2Q From: "Michel Py" To: "Alan E. Beard" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1G4vIQb013289 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan, > Alan E. Beard wrote: > No wonder we're at an impasse: we have a blind-men-and-the-elephant > problem here! No. We know what the elephant looks like. This is not the issue. The issue is that for the last eight years we have been trying to design an animal that carries as much as an elephant, at the speed of a cheetah, drinks as little as a camel, an possibly poops only in the toilet and flushes when done. > The common, underlying issue, as I see it, is: > The use of PA space in end-user networks has the effect of imposing > upon those networks functional burdens and restrictions in multiple > areas which the managers of commercial end-user networks may be > unwilling to tolerate. In consequence, we may need to reconsider > our current address allocation practice, which relies principally > on the PA model, in light of current user expectations, current > state of the routing protocols and standards, and anticipated > developments in routing and switching code. Given the rest of your postings, this appears to be a rather black-and-white view from the enterprise point of view. For the same reason multi6 has failed by limiting the scope to site multihoming, this approach is equally doomed to fail because it ignores the issues of large operators. There is some quality work that has been done in the field of PA multihoming solutions as well, such as: http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-01.txt Although the current IPv6 architecture indeed favors the large operator over the enterprise to the point that the enterprise network manager's feet feel the IPv6 water too cold to put more than the tip of the toe in (and this needs more balance), the other side of this coin is that if one wants to make a buck out of IPv6 today one has to look at Asia and to a lesser extent Europe for markets that involves a large percentage of mobile devices that are a good fit for the PA model. No bucks, no Buck Rogers. 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 Sat Feb 15 23:47:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1G7lSQb013644; Sat, 15 Feb 2003 23:47:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1G7lSxt013643; Sat, 15 Feb 2003 23:47:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1G7lNQb013636 for ; Sat, 15 Feb 2003 23:47:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1G7lXVK019162 for ; Sat, 15 Feb 2003 23:47:33 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20173 for ; Sat, 15 Feb 2003 23:47:27 -0800 (PST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AF1B415214; Sun, 16 Feb 2003 16:47:34 +0900 (JST) Date: Sun, 16 Feb 2003 16:47:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Fred L. Templin" Cc: ipng@sunroof.eng.sun.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: <3E47F0D0.5070802@iprg.nokia.com> References: <3E47F0D0.5070802@iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 10 Feb 2003 10:34:56 -0800, >>>>> "Fred L. Templin" said: > I wonder if the setting of the "L" bit in Prefix Information options > also bears some mention in this section. RFC 2461, section 4.6.2 says: > "When (the L bit is) not set, the advertisment makes no statement > about on-link or off-link properties of the prefix. For instance, > the prefix might be used for address configuration with some of > the addresses belonging to the prefix being on-link and others > being off-link." > Does this mean that prefix information options with the L bit not > set can be used to auto-configure off-link global or site-local > addresses? I don't think so. The L bit is irrelevant to address configuration. 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 Sun Feb 16 10:46:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GIkEQb014488; Sun, 16 Feb 2003 10:46:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1GIkEoj014487; Sun, 16 Feb 2003 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GIkAQb014480 for ; Sun, 16 Feb 2003 10:46:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1GIkJVK004925 for ; Sun, 16 Feb 2003 10:46:19 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.195]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04459 for ; Sun, 16 Feb 2003 11:46:13 -0700 (MST) Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h1GIk59c059413; Sun, 16 Feb 2003 13:46:06 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h1GIk5Nx056857; Sun, 16 Feb 2003 13:46:05 -0500 (EST) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h1GIk4Wi056854; Sun, 16 Feb 2003 13:46:05 -0500 (EST) Date: Sun, 16 Feb 2003 13:46:04 -0500 (EST) From: "Alan E. Beard" To: Michel Py cc: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C08@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030216075204.C43282-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel: On Sat, 15 Feb 2003, Michel Py wrote: > Alan, > > > Alan E. Beard wrote: > > No wonder we're at an impasse: we have a blind-men-and-the-elephant > > problem here! > > No. We know what the elephant looks like. This is not the issue. The > issue is that for the last eight years we have been trying to design an > animal that carries as much as an elephant, at the speed of a cheetah, > drinks as little as a camel, an possibly poops only in the toilet and > flushes when done. > In the context of the overall architecture and design of the protocol, you are, of course, right. It seems a bit hyperbolic to suggest that we don't have a reasonable conception of the overall architecture of IPv6. The blind-men-and-the-elephant metaphor was advanced in the context of the address allocation practices discussion. It does seem, at least to this observer, that we have a number of groups working on discrete issues which, in aggregate, may arise from a common root cause, and that an acknowlegment of that common root cause has so far been, at best, tacit. > > > The common, underlying issue, as I see it, is: > > The use of PA space in end-user networks has the effect of imposing > > upon those networks functional burdens and restrictions in multiple > > areas which the managers of commercial end-user networks may be > > unwilling to tolerate. In consequence, we may need to reconsider > > our current address allocation practice, which relies principally > > on the PA model, in light of current user expectations, current > > state of the routing protocols and standards, and anticipated > > developments in routing and switching code. > > Given the rest of your postings, this appears to be a rather > black-and-white view from the enterprise point of view. For the same > reason multi6 has failed by limiting the scope to site multihoming, this > approach is equally doomed to fail because it ignores the issues of > large operators. > This criticism would be both valid and compelling if the proposal cited above had been worded more narrowly than the text shows. In fact, the call for reconsideration does not ignore the interests of the large operators: the specific text is :"in light of current user expectations". Last time I looked, the class "user" subsumed the class of large operators, as well as privately operated networks (commercial and otherwise), academic networks, retail ISPs, and others. Granted, the problem statement does include a specific reference to commercial operators of private networks. We have been dealing with a number of technical issues which have adverse impact on that class of network. However, the deleterious effects are not limited to privately-operated commercial end-user networks. Perhaps a broader problem statement is in order, but the fundamental issue remains. If the call for reconsideration had been worded to exclude any one or more of the classes of network users, or to be so narrowly specific as to admit _only_ the interests of selected classes of network users, the criticism of "black-and-white view from the enterprise point of view" would be irrefutable; however, such is not the case, and the criticism fails on that ground. > There is some quality work that has been done in the field of PA > multihoming solutions as well, such as: > http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-01.txt > There is no suggestion (at least to my memory) that the work cited above, and others of like character, should not be part of the solution space. The specific work cited would be rendered inapplicable only if use of PA space were abandoned entirely for all or most classes of users; since no proposal to abandon PA exists (nor is any such proposal anticipated - more on this below), we should reasonably expect work such as that cited above to continue and, wherever shown technically sound, to see actual service in production networks. The general tenor of the comments above (and to some extent, of that below) appears to proceed from an assumption that the writer of the original call for discussion (and, before the question is raised, I did indeed write the text of the call for discussion) presupposes an outcome similar to: "abandon PA (largely or entirely); use PI as the preferred addressing model; and leave the transport and service providers to deal with the consequences, whatever they may be". I can state from direct and authoritative knowledge that the writer of the call for discussion presupposes no particular outcome whatsoever. Furthermore, the writer of the text of the call for discussion would be very likely to oppose any outcome of sort suggested above as signally irresponsible, and unworkable in practice, given the present state of our technologies. Given the way the IESG, the IETF, and this working group opreate, it would be grossly presumptous of any person to presuppose any particular outcome, or even to hold expectations concerning the character or the outline of any such outcome. > Although the current IPv6 architecture indeed favors the large operator > over the enterprise to the point that the enterprise network manager's > feet feel the IPv6 water too cold to put more than the tip of the toe in > (and this needs more balance), the other side of this coin is that if > one wants to make a buck out of IPv6 today one has to look at Asia and > to a lesser extent Europe for markets that involves a large percentage > of mobile devices that are a good fit for the PA model. > The statement immediately above seems a good summary of the general state of our current address allocation philosophy and the technical issues attendant thereunto. Yes, it would appear that PA space is probably appropriate for several classes of use, and that use of PA space probably should not be abandoned. However, as pointed out above, more balance is indeed needed with regard to address allocation policy for some classes of users: it may not be desirable to continue to prefer PA allocations (to the nearly total exclusion of other models) for at least some user groups. Let's talk the matter over, shall we? > No bucks, no Buck Rogers. > > Michel. > Personal note: Michel, your last paragraph above indicates, at least by my interpretation, that you and I are really after the same objective: a technically sound and balanced policy which will faciltate the widest possible acceptance and implementation IPv6 in both pubic and private networks. Thank you for your comments, and for providing this opportunity to correct any misapprehensions which may have arisen concerning the nature and intent of the call for discussion. Regards, Alan -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 16 14:44:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GMiqQb015033; Sun, 16 Feb 2003 14:44:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1GMiqGX015032; Sun, 16 Feb 2003 14:44:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GMimQb015025 for ; Sun, 16 Feb 2003 14:44:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1GMivVL019019 for ; Sun, 16 Feb 2003 14:44:57 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12307 for ; Sun, 16 Feb 2003 15:44:51 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1GMjnhE000736; Sun, 16 Feb 2003 23:45:50 +0100 (CET) Date: Sun, 16 Feb 2003 20:30:42 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Chown , To: "Alan E. Beard" From: Kurt Erik Lindqvist In-Reply-To: <20030214175244.P43282-100000@amneris.aebeard.net> Message-Id: <2356C4F3-41E5-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> (Randy removed from CC as I only had him in CC for the comments on the RIPE meeting) >>> Most end-user network managers I deal with require these >>> characteristics >>> of their public network address allocations: >>> >>> 1) uniqueness (sometimes expressed as "autonomy") >> >> Wait. This is interesting. From what people here was saying before - I >> drew the conclusion that end-users wanted non-uniqueness aka >> site-locals to hide their topology. You are saying something else? >> > Please note the keyword "public" in the statement above. This applies > (in > the cases of most of my clients) to address spaces which are > advertised to > the public networks (AKA The Internet). [snip] > Given the choice, most (in fact, nearly all) of my clients would > prefer to > run their internal networks on registered, unique, globally routable > address space; this greatly simplifies the task of providing access to > resources on the public network, and of providing access from the > public > networks to resouces which the external customers of the business > desire > to use, usually with the result of generating revenue for the business. > Furthermore, the use of unique, globally routable address space vastly > simplifies the task of establishing connections to networks operated by > business partners (eg, vendors and larger customers), whether via the > public network or over private links. However, my clients are wholly > unwilling to run even the slightest risk of a forced renumbering on > their > internal networks. Full stop. No exceptions, and no equivocations. I still like what I read. > If unique and stable globally routable space is not available for use > in > their internal networks, my clients see non-unique, globally > non-routable > space, coupled with NAT, as a feasible (but not desirable) > alternative: at > least they have a reasonable expectation that such addressing will be > stable, and that a forced renumbering is unlikely. For IPv6, the site > local space meets the requirement for internal networks of address > stability. That the SL (or, for IPv4, PNN) space is globally > non-routable Well, SLs are more or less RFC1918 all over. (at least in my view) >>> 3) stability >> >> Do you mean as a derivate of portability or for some other reason? >> > No. The stability requirement is quite independent of portability. My > clients desire to avoid renumbering at any cost short of summary > hanging; > where it is not posiible to avoid renumbering, they wish to renumber as > few systems as possible, and they would much rather change a static > translation mapping than reconfigure a host. Where these clients are I would still claim that his is a side effect of portable address space. >>> Most of the end-user-network managers among my clients now multihome, >>> and >>> will continue to require multihomed service in future. In every case >>> where the user's network is multihomed, the multiple independent >>> connections are seen as crucial for maintenance of high availability >>> of >> >> I find this funny. A number of studies have shown that if this is what >> you are after, multihoming and BGP is the wrong way to go - but never >> mind. >> > Your comment may be true, but my clients are nonetheless unwilling to > risk > the possibility of an extended network outage on a single ISP (while > not > frequent, these events are far from unprecedented) rendering their > online > customer-support environment unavailable for several hours, much less > for > a day. Shorter outages (on the order of minutes in the single digits) > are > tolerated, provided that such outages are infrequent. Well, there are a number of ways to minimize such effects as well. And there are a number of ways you could engineer around this with other methods than Globally Routable PI space. Regards, - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 16 14:45:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GMj7Qb015043; Sun, 16 Feb 2003 14:45:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1GMj7kh015042; Sun, 16 Feb 2003 14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1GMj1Qb015035 for ; Sun, 16 Feb 2003 14:45:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1GMj5VL019036 for ; Sun, 16 Feb 2003 14:45:05 -0800 (PST) Received: from dhcp-168-17-67.autonomica.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12355 for ; Sun, 16 Feb 2003 15:44:59 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1GMjvhE000749; Sun, 16 Feb 2003 23:45:59 +0100 (CET) Date: Sun, 16 Feb 2003 21:05:58 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tony Hain , Michel Py , "Fred L. Templin" , ipng@sunroof.eng.sun.com To: "Alan E. Beard" From: Kurt Erik Lindqvist In-Reply-To: <20030215075112.O43282-100000@amneris.aebeard.net> Message-Id: <10684B40-41EA-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > read Tony's ipv6ipaddressusage-04 draft > read Michel's gapi-00 draft > reviewed the site-local use discussion in the IPv6 WG > read the Multi6 charter > read the Multi6 requirements draft > re-read RFC 2373 and RFC 2374 > re-read the addr-arch-v3 draft > re-read the ipv6-prefix-delegation-requirement-00 draft > re-read the ipv6-ipaddressassign-06 draft > read Iljitch van Beijnum's multi6-isp-int-aggr-00 draft > read Michel's Multi Homing Aliasing Protocol draft Hey you forgot multihoming-longprefix-00.txt! :) > 1) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6 > task list a work item which directs the WG to coordinate and support > extant activities in other WGs which deal with issues surrounding use > of > PA and PI address spaces in, or at the boundaries of, end-user > networks. > (Note: this language will need to be clarified. Suggestions welcome.) > > This is incontestably within the working group charter, as indicated by > this charge in the charter statement: > > - Serve as a review board and body of competence and coordination for > IPv6 > architectural issues that span multiple IETF working groups. > This is not a IPv6 problem. It's a routing problem at best. If we continue to have the IPv6 groups to work on behalf on other groups we will not get far. I have no clear solution to this, but I strongly disagree to put this under the IPv6 WG. This might belong in IDR, but I guess that would require to re-charter IDR. I think that you to some extent are right in your observations. This is a problem that will impact the solution of a number of other problems, as these will impact a number of possible solutions to PI vs PA. However, me (and I think a number of other people) are starting to think that everything discussed so far is just pointing to us trying to paint IPv6 in nice colors to try and hide it's ugly shapes. Maybe the problem is somewhere else and a lot deeper. This seems to be a lot more politically sensitive to bring up though. Best regards, - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 17 08:09:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HG9xQb017794; Mon, 17 Feb 2003 08:09:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1HG9xTq017793; Mon, 17 Feb 2003 08:09:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HG9uQb017786 for ; Mon, 17 Feb 2003 08:09:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1HGA4VL028357 for ; Mon, 17 Feb 2003 08:10:04 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15487 for ; Mon, 17 Feb 2003 09:09:58 -0700 (MST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1HG8j224626 for ; Mon, 17 Feb 2003 18:08:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 17 Feb 2003 18:09:55 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Feb 2003 18:09:55 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Feb 2003 18:09:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Mon, 17 Feb 2003 18:09:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLRNAY1MEILAXXWQomes97NRpDphABrZFiA To: , X-OriginalArrivalTime: 17 Feb 2003 16:09:55.0397 (UTC) FILETIME=[02BE5F50:01C2D69F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1HG9uQb017787 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Fred, > I wonder if the setting of the "L" bit in Prefix Information options > also bears some mention in this section. RFC 2461, section 4.6.2 says: > > "When (the L bit is) not set, the advertisment makes no statement > about on-link or off-link properties of the prefix. For instance, > the prefix might be used for address configuration with some of > the addresses belonging to the prefix being on-link and others > being off-link." > > Does this mean that prefix information options with the L bit not > set can be used to auto-configure off-link global or site-local > addresses? Do you have some suggestion of text to add? thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 17 09:56:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HHuBQb018240; Mon, 17 Feb 2003 09:56:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1HHuAxr018239; Mon, 17 Feb 2003 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HHu7Qb018232 for ; Mon, 17 Feb 2003 09:56:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1HHuEVL015715 for ; Mon, 17 Feb 2003 09:56:14 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12305 for ; Mon, 17 Feb 2003 10:56:08 -0700 (MST) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 17 Feb 2003 09:56:06 -0800 Reply-To: From: "Tony Hain" To: "'Alan E. Beard'" , "'Michel Py'" , "'Fred L. Templin'" Cc: Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 17 Feb 2003 09:56:08 -0800 Message-ID: <008901c2d6ad$d99349b0$9e104104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030215075112.O43282-100000@amneris.aebeard.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1HHu7Qb018233 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan E. Beard wrote: > Folks: > > OK. In the past several days, I have: > > read Tony's ipv6ipaddressusage-04 draft > read Michel's gapi-00 draft > reviewed the site-local use discussion in the IPv6 WG > read the Multi6 charter > read the Multi6 requirements draft > re-read RFC 2373 and RFC 2374 > re-read the addr-arch-v3 draft > re-read the ipv6-prefix-delegation-requirement-00 draft > re-read the ipv6-ipaddressassign-06 draft > read Iljitch van Beijnum's multi6-isp-int-aggr-00 draft > read Michel's Multi Homing Aliasing Protocol draft > > I went back and ploughed through my archive of ngtrans mail. > > At one point I thought I had got myself into a configuration > which features a permanently recirculating digestive system. 8-/ And you are still coherent enough to send mail?!?! > ... > > > We are at an impass. > > > > Indeed. > > > > > No wonder we're at an impasse: we have a > blind-men-and-the-elephant problem here! > > Each of the discussions and drafts cited above defines a > problem, and, in most cases, proposes a solution for that > problem or a tool to help constrain the problem space. As I > read the documents and discussion logs, all the problems > described converge on a common underlying root issue. In > effect, each group or author has siezed upon one aspect of > the root issue (one the trunk; another an ear, the third a > leg; ...) and then described a possible solution for that > aspect of the issue. Well, I would describe it more as trying to find the balance point between a divergent set of contradictory requirements. > > I suggest that we might be able to make more progress if we > directly address the underlying issue. This is not to > sugggest that the problems severally described in the > citations above will automagically disappear once the root > issue is resolved; however, I think that most (probably all) > of the discrete problems will then become much easier to solve. > > The common, underlying issue, as I see it, is: > > The use of PA space in end-user networks has the effect of > imposing upon those networks functional burdens and > restrictions in multiple areas which the managers of > commercial end-user networks may be unwilling to tolerate. While this is a problem statement that has been missing from the historical discussions, it would fit more in the elephant metaphor bucket. The fundamental problem is that decisions get made without all interested parties having a voice. > ... > Additionally, there is no task open which deals directly with > the user-community concerns over the functional burdens > imposed on end-user networks by forced use of PA. Well, arguably the multi6 wg is supposed to be considering the input of the multihoming sites. Unfortunately the route scaling camp continues to drown out that input with claims that we only know how to scale PA unless we rearchitect the entire Internet with route scaling as its primary focus. > ... > Now, I intend to make a specific proposal on next steps > below, and then pose these questions: > > 1) Should we ask for something akin to the steps proposed below? Akin, yes. Directing where the work gets done, probably not. > > 2) Is there another approach which will work at least as > well, and, if so, what is it? Maybe something as simple as an informational RFC written by edge network managers. Such a document should state a set of requirements that the architectural & operational working groups would need to meet. Your mail in this thread provides a good starting point, and I am sure we could find a few others with an edge perspective to participate. One thing I would caution, in addition to stating that renumbering is not tolerable, there should be some documentation of the reasoning. Having forgotten about many of the unusual places people stick addresses, I had convinced myself that most of the objection to renumbering hosts was the painful process of doing it in IPv4. We worked hard to make renumbering the host itself a non-issue, but overlooked all the obscure places people stick explicit addresses. > > 3) Are we approaching this matter hind-end-foremost? No, but it probably feels that way. > > or > > 4) I am the functional equivalent of a skunk with his head > stuck in a tin can? (Alternately expressed: is this proposal > fundamentally wrong-headed, and should we abandon it in favor > or more productive discussions?) > > Here is a starting point for discussion of next steps. We > may wish to: > > 1) Ask the IPv6 WG chairs and the Internet Area ADs to add to > the IPv6 task list a work item which directs the WG to > coordinate and support extant activities in other WGs which > deal with issues surrounding use of PA and PI address spaces > in, or at the boundaries of, end-user networks. > (Note: this language will need to be clarified. Suggestions welcome.) > > This is incontestably within the working group charter, as > indicated by this charge in the charter statement: > > - Serve as a review board and body of competence and > coordination for IPv6 architectural issues that span multiple > IETF working groups. Well I would agree, except the intent of multi6 was to address all of the issues consistently within one focused working group. Reality is another story. > > 2) Ask the IPv6 WG chairs and the Internet Area ADs to add to > the IPv6 task list a work item which directs the WG to review > and, if needed, recommend revisions to the current IPv6 > unicast address allocation practice in light of current user > expectations, current state of the routing protocols and > standards, and anticipated developments in routing and switching code. > > Here again, this is incontestably within the scope of the WG > charter, as indicated by this charge in the charter statement: > > - Provide technical input to the IAB, IANA and Internet > Address Registries with regard to IPv6 address allocation > policies and procedures. > > OK, let the gates down - I'm eager for comments. No objection to your desire to see progress, but maybe the simplest way forward would be to have a few edge network managers write a simple RFC that says, our requirements are X,Y,Z, and they are not being met by the current state of the standards. Achieving the goal of address stability requires either, SL+NAT using PA allocations, or PI. 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 17 12:27:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HKRuQb018794; Mon, 17 Feb 2003 12:27:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1HKRuuR018793; Mon, 17 Feb 2003 12:27:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1HKRqQb018786 for ; Mon, 17 Feb 2003 12:27:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1HKS1VL011504 for ; Mon, 17 Feb 2003 12:28:01 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29399 for ; Mon, 17 Feb 2003 12:27:55 -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 MAA17341 for ; Mon, 17 Feb 2003 12:27:55 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1HKRss16835; Mon, 17 Feb 2003 12:27:54 -0800 X-mProtect: <200302172027> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2N5lSa; Mon, 17 Feb 2003 12:27:53 PST Message-ID: <3E514668.1060402@iprg.nokia.com> Date: Mon, 17 Feb 2003 12:30:32 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, john.loughney@nokia.com wrote: > Hi Fred, > > >>I wonder if the setting of the "L" bit in Prefix Information options >>also bears some mention in this section. RFC 2461, section 4.6.2 says: >> >> "When (the L bit is) not set, the advertisment makes no statement >> about on-link or off-link properties of the prefix. For instance, >> the prefix might be used for address configuration with some of >> the addresses belonging to the prefix being on-link and others >> being off-link." >> >>Does this mean that prefix information options with the L bit not >>set can be used to auto-configure off-link global or site-local >>addresses? > > > Do you have some suggestion of text to add? Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on the subject. RFC 2461, section 6.3.4 ("Processing Received Router Advertisements") says: Prefixes with the on-link flag set to zero would normally have the autonomous flag set and be used by [ADDRCONF]. But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle prefix options with the on-link flag ("L") set to zero! I believe the Node Requirements document is the right place to resolve the ambiguity; I'm just not sure what that resolution should be. Fred ftemplin@iprg.noka.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 Mon Feb 17 19:20:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1I3KRQb019867; Mon, 17 Feb 2003 19:20:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1I3KRLY019866; Mon, 17 Feb 2003 19:20:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1I3KOQb019859 for ; Mon, 17 Feb 2003 19:20:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1I3KWVK005383 for ; Mon, 17 Feb 2003 19:20:32 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22787 for ; Mon, 17 Feb 2003 20:20:26 -0700 (MST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1I3KI6C044602; Mon, 17 Feb 2003 22:20:18 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-253-252.mts.ibm.com [9.65.253.252]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1I3KGPd030376; Mon, 17 Feb 2003 20:20:17 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1I3Hxh02586; Mon, 17 Feb 2003 22:17:59 -0500 Message-Id: <200302180317.h1I3Hxh02586@cichlid.adsl.duke.edu> To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: Message from ftemplin@iprg.nokia.com of "Mon, 17 Feb 2003 12:30:32 PST." <3E514668.1060402@iprg.nokia.com> Date: Mon, 17 Feb 2003 22:17:58 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Fred L. Templin" writes: > >>I wonder if the setting of the "L" bit in Prefix Information options > >>also bears some mention in this section. RFC 2461, section 4.6.2 says: > >> > >> "When (the L bit is) not set, the advertisment makes no statement > >> about on-link or off-link properties of the prefix. For instance, > >> the prefix might be used for address configuration with some of > >> the addresses belonging to the prefix being on-link and others > >> being off-link." > >> > >>Does this mean that prefix information options with the L bit not > >>set can be used to auto-configure off-link global or site-local > >>addresses? No. The wording really does says what it is supposed to say. If the L bit is is not set, one cannot say anything about whether the prefix is on-link or off link. Specifically, a sender cannot assume that other addresses covered by that prefix are on-link and send packets directly to them; instead, packets for those destinations must be sent to a router. But it may (or may not) be the case that the destination is on the same link as the original sender. If it is, the router will forward the packet back to the same link. It may (or it may not) also send a redirect to the sending node. This is a feature that allows a router to arrange to have all traffic forwarded to it, even for destinations that are directly reachable. It also (possibly) helps support things like multi-link subnets, where some destinations may be on one link, but others on a different link, but both covered by the same prefix. > > Do you have some suggestion of text to add? > Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on > the subject. RFC 2461, section 6.3.4 ("Processing Received Router > Advertisements") says: > Prefixes with the on-link flag set to zero would normally have the > autonomous flag set and be used by [ADDRCONF]. > But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle > prefix options with the on-link flag ("L") set to zero! The point is that if the bit is set, one assumes all destinations covered by the prefix are on link. If it is not set, you can't assume that and one does nothing. > I believe the Node Requirements document is the right place to resolve > the ambiguity; I'm just not sure what that resolution should be. Does the above explanation help? I.e., do you still believe there is an ambiguity? 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 18 05:21:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IDL9Qb022260; Tue, 18 Feb 2003 05:21:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IDL9j9022259; Tue, 18 Feb 2003 05:21:09 -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.8+Sun/8.12.8) with ESMTP id h1IDL5Qb022252 for ; Tue, 18 Feb 2003 05:21:05 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1IDL8P27894; Tue, 18 Feb 2003 14:21:09 +0100 (MET) Date: Tue, 18 Feb 2003 14:17:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Bob Hinden Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20030213153511.036d4608@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is OK for me. I will plan add it to the next version of the > draft. Would you like to be listed as an author? I don't have a problem with that, but I suspect my wording can benefit from some editorial tweaks. > > > What did you have in mind that might further clarify this issue? > > > >Remove "for the 2000::/3 Prefix" from the title and remove > >the mention of the specific prefix from the text. > > OK, that is clearer. It wouldn't be too hard to make this change, but > there doesn't seem to be complete agreement on the list for this change. > > >Apart from the restriction to 2000::/3 I don't see how section 2.0 adds > >anything beyond what is in addr-arch. Perhaps I'm missing something. > > I think it provides a summary of what the resulting address format for this > prefix (and other prefixes if the above change is made). Since we now seem > to heading toward a non-standards track document, what is the harm? Hmm - based on Brian's comment it might make sense to say that the document explicitly redefines the structure in 2000::/3 to be the god'ol basic addr-arch structure of "bits+subnet+iid". Thus having section 2.0 to explicitly point out that this is the replacement for the format in 2374 makes sense to me. But the "replacement" part needs to be made very clear. > I now agree that it can be non-standards track. What was your objection to > making it a BCP? In some ways this is the best current practice. I don't see any "practise" in the document. Perhaps I'm missing something. If there is practise, for instance suggesting that the same address format can be useful for both providers and exchanges, then BCP might make more sense. But it isn't clear to me whether the WG sees the benefits of restating that aspect of 2374 in this document. 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 18 05:26:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IDQvQb022336; Tue, 18 Feb 2003 05:26:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IDQvMk022335; Tue, 18 Feb 2003 05:26:57 -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.8+Sun/8.12.8) with ESMTP id h1IDQrQb022328 for ; Tue, 18 Feb 2003 05:26:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1IDQxP28523; Tue, 18 Feb 2003 14:27:00 +0100 (MET) Date: Tue, 18 Feb 2003 14:23:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <963621801C6D3E4A9CF454A1972AE8F54BFC@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 > Proposed title: "IPv6 Global Unicast Address Format" ok > Proposed text: > > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 > for now, IANA might allocate unassigned parts of the IPv6 address space > to Global Unicast later. Isn't there some other document which contains the IETF's recommendation to IANA to hand out IPv6 prefixes to the RIRs? It would be better if we can refer to a document (which might evolve on its own) than explicitly state the range of prefixes in this document because that means that should IANA start handing out prefixes outside of 2000::/3 this document will become inconsistent with reality. 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 18 05:29:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IDTdQb022381; Tue, 18 Feb 2003 05:29:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IDTchB022380; Tue, 18 Feb 2003 05:29:38 -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.8+Sun/8.12.8) with ESMTP id h1IDTYQb022370 for ; Tue, 18 Feb 2003 05:29:34 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1IDTdP28704; Tue, 18 Feb 2003 14:29:39 +0100 (MET) Date: Tue, 18 Feb 2003 14:25:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <963621801C6D3E4A9CF454A1972AE8F54BFE@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 > That being said, I have contradictory / ambiguous feelings about the > omission of "SLA". Here's the contradiction: > > - On one side, since you explicitly kill TLA and NLA but not SLA, it is > permitted to think that SLA is not completely dead, which suits me fine > since my position is that although moving it to policy was a good idea, > killing the notion of site boundary was not. > > - On the other side, if SLA is not dead it's not alive either, which > makes it a zombie I guess. This is not good, and one of these nights, > when the moon is full, it will rise from the grave like in Michael > Jackson's "thriller" and come haunt us. > > Therefore, we have three options for SLA: > 1. Don't change the text and keep it a zombie. > 2. Kill it (which I don't like). > 3. Spare it; the idea being that what we want to do is move it to policy > but don't kill the notion that a site boundary exists. This is what RIRs > call a "soft" or "semi-hard" boundary. I think the "SLA" field in 2374 has been replaced by the "subnet ID" field in addr-arch-v3. It probably makes sense to make this clear by adding a note e.g. The SLA (subnet local aggregator) field in RFC 2374 remains in function but with a different name in [ADDR-ARCH]; its new name is "subnet ID". 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 18 05:47:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IDlGQb022617; Tue, 18 Feb 2003 05:47:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IDlG5c022616; Tue, 18 Feb 2003 05:47: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.8+Sun/8.12.8) with ESMTP id h1IDlCQb022609 for ; Tue, 18 Feb 2003 05:47:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1IDlJP00871; Tue, 18 Feb 2003 14:47:19 +0100 (MET) Date: Tue, 18 Feb 2003 14:43:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Pekka Savola 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using > MLD) -- May 2002. > > ==> basically the MLD protocol is used to signal anycast joins/leaves. > However, critical part which seems to be missing here is "interactions of > anycast-MLD with routing", as with multicast. > > There are a _lot_ of issues there, especially if one anycast address can > have joins from across multiple routers. Even more so if from across > multiple sites/AS's, or more specifically (with some terminology pixie > dust) an IGP/iBGP area -- a region where propagating host routes is > acceptable. But I'd recommend sticking to a site, the rest is way too > difficult for now. I agree that there are issues like that. But those issues are independent of the protocol mechanism (MLD, RIPng, OSPFv3, ISIS, BGP - gawk!) that is used to carry the routes from the host to the router. The authorization independently of the protocol. > Thus by far the easiest way to enable anycast on hosts seems to be a > requirement for them to participate in a routing protocol. Something like > BGP is good for this (not ideal: too much weight). Simpler protocols can > of course also be used; the most important thing is to pick one which > allows your neighbor(s) to filter out any advertisements excluding the > anycast addresses(es) -- so that you can't hose the routing to other than > the anycast address(es) itself even in the worst case scenario. BGP??? I think there is some operational experience that configuring a routing protocol on the hosts for the sole purpose of announcing one or more (anycast) source routes adds a lot of complexity. Not only does the host need to implement a routing protocol which interoperates with what the routers run, you also need to prevent the host from ever being used for forwarding. If the host is multi-interfaced this might be quite tricky and error prone. Thus having a separate host-to-router protocol with limited functionality seems to make sense to me. > ==> of course, this is more than just DoS. This is packet capture and a > man-in-the-middle attack too. Yep. > To prevent such attacks, it is expected that routers will employ > some filtering mechanism when receiving a Report message containing > a non-multicast address. For example, one policy might be to deny > all anycast joins except those that match a configured list of > (source address, anycast address) pairs. > > ==> the problems with such a measure seems to be that: > 1) MLD message does not signify other than link-local addresses AFAIR > 2) some addresses are easily spoofed. > > Of course, to be complete, some "reverse-path verification" for addresses, > if routable unicast, would have to be done. How would reverse-path help with the authorization issue (which node can "join" e.g. the "sun-ntp-server" anycast address? Short of CGA techniques (where the host would be challenged to prove that it has the private key corresponding to the CGA anycast address) I don't see a scheme which doesn't require manual configuration of an access list on the router. > 2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using > Return Routability) -- Oct 2002. > > ==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping > update but the concept is clear. > > However, I'm just not so sure that this is the right, even if seemingly > sufficient, approach. The main concerns from the top of the head seem to > be: > > - the extent of MIPv6 support required to support this (I assume e.g. > binding cache is needed) yep > - the high number of packets exchanged before commencing with real TCP > traffic And the alternative is? > - the changes to TCP to run this operation at the reception of a specific > TCP SYN (perhaps this happens with MIPv6, but my impression has been that > in most cases, return routability is executed based on MN's own desire to > do send packets, not respond to some of them) > > - the different model of address ownership model; this seem the most > important. MIPv6 RR is used to prove that the MN has the right to use > certain care-of/home address. These are network-topology -independent, in > a sense; a part of an autoconfigured/statefully-configured prefix, freely > configurable by anyone on the link(s). > > Anycast is different: there the right target to ask for permission to > certify this binding would appear to be the routing system, or someone in > charge of specifying the -pair. I think that is the local problem - the first-hop router next to the anycast server. And that needs to be solved with some form of access control list. But even if that is solved it doesn't help the initiator of long-term communication with an anycast address to safely know the mapping between the anycast address and one unicast address which is part of the anycast group. The use of return-routability allows you to make statements about that binding with the same security level as for the MIPv6 return routability. > 3) that's it. > > My own, very raw idea for anycast + TCP: a new ICMP message, including the > seq number (or equivalent protocol-specific information) of the > just-received TCP SYN, indicating the unicast address which should be used > instead of the included anycast address. > > Of course, this brings up the problem of easily-guessable TCP seq numbers. > This could be mostly remedied by requiring (I wonder if this kind of > requirement would be sane..) that TCP implementations check their SYN_SENT > state tables that the packet has actually been sent to the the destination > very recently -- thus the window where a timing attack could be done would > be almost eliminated. And you have the option of the target to bomb a victim by saying "send your packets to Alice" even though Alice is not part of the anycast group. The use of RR prevents this, as well as provides something stronger than the TCP sequence number from a guessing perspective. > As an option, if the initiator would not believe this binding, some > stronger mechanisms could be applied (source address comparison, which is > not really valid except if we apply some new requiremens for anycast usage > -- like that to be used like this, the addresses must all be from the same > /64, /48, /32 or whatever *); RR tests; etc.). > > Of course, all of this would appear to be moot if something like IPsec was > used between the end-points. I must have missed the document which specifies how IPsec works with anycast 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 18 08:28:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IGSGQb023297; Tue, 18 Feb 2003 08:28:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IGSGWg023296; Tue, 18 Feb 2003 08:28:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IGSCQb023289 for ; Tue, 18 Feb 2003 08:28:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1IGSLVK021853 for ; Tue, 18 Feb 2003 08:28:22 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28507; Tue, 18 Feb 2003 09:28:11 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1IGRlWT026860; Tue, 18 Feb 2003 17:27:48 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1IGRagW145072; Tue, 18 Feb 2003 17:27:37 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34176 from ; Tue, 18 Feb 2003 17:27:35 +0100 Message-Id: <3E525EC2.EABE0A62@hursley.ibm.com> Date: Tue, 18 Feb 2003 17:26:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Erik Nordmark Cc: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > Proposed title: "IPv6 Global Unicast Address Format" > > ok > > > Proposed text: > > > > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > > which is formally made historic by this document. Although as specified > > in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 > > for now, IANA might allocate unassigned parts of the IPv6 address space > > to Global Unicast later. > > Isn't there some other document which contains the IETF's recommendation > to IANA to hand out IPv6 prefixes to the RIRs? The nearest we have is 3177, I think. Persuading IANA to hand out the top level prefixes was done by email. See http://www.iab.org/Documents/IPv6addressspace.txt (Hmm. It reads very optimistically today.) > > It would be better if we can refer to a document (which might evolve > on its own) than explicitly state the range of prefixes in this document > because that means that should IANA start handing out prefixes outside of > 2000::/3 this document will become inconsistent with reality. Well, some text could say that in slightly more formal language. 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 Tue Feb 18 10:42:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IIgCQb024671; Tue, 18 Feb 2003 10:42:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IIgCW2024670; Tue, 18 Feb 2003 10:42:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IIg8Qb024663 for ; Tue, 18 Feb 2003 10:42:08 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1IIgIVK006229 for ; Tue, 18 Feb 2003 10:42:18 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02287 for ; Tue, 18 Feb 2003 10:42:12 -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 KAA28210; Tue, 18 Feb 2003 10:42:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1IIgAV32553; Tue, 18 Feb 2003 10:42:10 -0800 X-mProtect: <200302181842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMMkEdL; Tue, 18 Feb 2003 10:42:09 PST Message-ID: <3E527F25.5020106@iprg.nokia.com> Date: Tue, 18 Feb 2003 10:44:53 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <200302180317.h1I3Hxh02586@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I'm still of the opinion that some ambiguity exists. Namely, if a prefix option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit) NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK to go ahead and configure an address from the (off-link) prefix as specified in 5.5.3 d). But then, which link would one derive an interface identifier from in order to form an address? (And, which interface would one assign the address to?) I believe this should be clarified somewere, e.g., in the IPv6 node reqt's document. The challenge is in specifying something that is neither too precise that it precludes legitimate functionality nor too broad that it opens the door to security holes and/or misconfigurations. In particular, if it's not OK for a node to configure an address from an advertised prefix with the "L" bit not set we should probably say so somewhere and give some rationale. Regards, Fred ftemplin@iprg.nokia.com Thomas Narten wrote: > "Fred L. Templin" writes: > > >>>>I wonder if the setting of the "L" bit in Prefix Information options >>>>also bears some mention in this section. RFC 2461, section 4.6.2 says: >>>> >>>> "When (the L bit is) not set, the advertisment makes no statement >>>> about on-link or off-link properties of the prefix. For instance, >>>> the prefix might be used for address configuration with some of >>>> the addresses belonging to the prefix being on-link and others >>>> being off-link." >>>> >>>>Does this mean that prefix information options with the L bit not >>>>set can be used to auto-configure off-link global or site-local >>>>addresses? >>> > > No. The wording really does says what it is supposed to say. If the L > bit is is not set, one cannot say anything about whether the prefix is > on-link or off link. Specifically, a sender cannot assume that other > addresses covered by that prefix are on-link and send packets directly > to them; instead, packets for those destinations must be sent to a > router. > > But it may (or may not) be the case that the destination is on the > same link as the original sender. If it is, the router will forward > the packet back to the same link. It may (or it may not) also send a > redirect to the sending node. > > This is a feature that allows a router to arrange to have all traffic > forwarded to it, even for destinations that are directly reachable. > It also (possibly) helps support things like multi-link subnets, where > some destinations may be on one link, but others on a different link, > but both covered by the same prefix. > > >>>Do you have some suggestion of text to add? >> > >>Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on >>the subject. RFC 2461, section 6.3.4 ("Processing Received Router >>Advertisements") says: > > >> Prefixes with the on-link flag set to zero would normally have the >> autonomous flag set and be used by [ADDRCONF]. > > >>But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle >>prefix options with the on-link flag ("L") set to zero! > > > The point is that if the bit is set, one assumes all destinations > covered by the prefix are on link. If it is not set, you can't assume > that and one does nothing. > > >>I believe the Node Requirements document is the right place to resolve >>the ambiguity; I'm just not sure what that resolution should be. > > > Does the above explanation help? I.e., do you still believe there is > an ambiguity? > > 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 18 12:19:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IKJAQb025045; Tue, 18 Feb 2003 12:19:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IKJA6g025044; Tue, 18 Feb 2003 12:19:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IKJ6Qb025037 for ; Tue, 18 Feb 2003 12:19:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1IKJFVK008445 for ; Tue, 18 Feb 2003 12:19:15 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23268 for ; Tue, 18 Feb 2003 13:19:10 -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 MAA28440; Tue, 18 Feb 2003 12:20:19 -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 MAA18187; Tue, 18 Feb 2003 12:20:17 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA03890; Tue, 18 Feb 2003 12:23:54 -0800 (PST) Date: Tue, 18 Feb 2003 12:23:54 -0800 (PST) From: Tim Hartrick Message-Id: <200302182023.MAA03890@feller.mentat.com> To: narten@us.ibm.com, ftemplin@iprg.nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Cc: ipng@sunroof.eng.sun.com, john.loughney@nokia.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, I have myself been confused by the L bit in the past but I don't think there is anywhere near as much ambiguity here as you. And, if there is the node requirements document isn't the place to fix it. > > I'm still of the opinion that some ambiguity exists. Namely, if a prefix > option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit) > NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK > to go ahead and configure an address from the (off-link) prefix as specified > in 5.5.3 d). But then, which link would one derive an interface identifier > from in order to form an address? (And, which interface would one assign > the address to?) > It is correct to infer that one should configure an address from a prefix option with the A bit set and the L bit clear. Is it really necessary to spell out that the address should be configured on the interface on which the advertisement was received? What would justify making any other choice? Tim Hartrick Mentat 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 Tue Feb 18 13:53:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ILruQb025755; Tue, 18 Feb 2003 13:53:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1ILrufR025754; Tue, 18 Feb 2003 13:53:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ILrqQb025747 for ; Tue, 18 Feb 2003 13:53:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1ILs2VK012040 for ; Tue, 18 Feb 2003 13:54:02 -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 OAA29386 for ; Tue, 18 Feb 2003 14:53:55 -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 NAA05186; Tue, 18 Feb 2003 13:53:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1ILrql23107; Tue, 18 Feb 2003 13:53:52 -0800 X-mProtect: <200302182153> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyQyKUn; Tue, 18 Feb 2003 13:53:51 PST Message-ID: <3E52AC14.6040300@iprg.nokia.com> Date: Tue, 18 Feb 2003 13:56:36 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Hartrick CC: narten@us.ibm.com, ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <200302182023.MAA03890@feller.mentat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Tim Hartrick wrote: > Fred, > > I have myself been confused by the L bit in the past but I don't think > there is anywhere near as much ambiguity here as you. And, if there is > the node requirements document isn't the place to fix it. > >>I'm still of the opinion that some ambiguity exists. Namely, if a prefix >>option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit) >>NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK >>to go ahead and configure an address from the (off-link) prefix as specified >>in 5.5.3 d). But then, which link would one derive an interface identifier >>from in order to form an address? (And, which interface would one assign >>the address to?) > > It is correct to infer that one should configure an address from a prefix > option with the A bit set and the L bit clear. Is it really necessary to > spell out that the address should be configured on the interface on which > the advertisement was received? What would justify making any other choice? Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure addresses for prefix options with the "A" bit set; the "L" bit is don't-care. But, RFC 2461 (section 6.3.4) says that "a prefix information option with the on-link flag set to zero conveys no information concerning on-link determination", i.e., you can't tell whether the prefix is on/off link. But, if you configure an address from a prefix option with the "L" bit set to zero and assign it to the interface the RA arrived on, you are in effect declaring that at least one /128 chunk of the prefix is on-link. But, I don't see any text in RFC 2461 that says you can assume this. This is where I see the ambiguity. Fred ftemplin@iprg.nokia.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 18 14:20:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IMKuQb025948; Tue, 18 Feb 2003 14:20:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IMKtGn025947; Tue, 18 Feb 2003 14:20:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IMKpQb025940 for ; Tue, 18 Feb 2003 14:20:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1IML1VK020903 for ; Tue, 18 Feb 2003 14:21:01 -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 PAA15991 for ; Tue, 18 Feb 2003 15:20:55 -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 OAA29215; Tue, 18 Feb 2003 14:22:12 -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 OAA25002; Tue, 18 Feb 2003 14:22:11 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA03917; Tue, 18 Feb 2003 14:25:47 -0800 (PST) Date: Tue, 18 Feb 2003 14:25:47 -0800 (PST) From: Tim Hartrick Message-Id: <200302182225.OAA03917@feller.mentat.com> To: ftemplin@iprg.nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com, john.loughney@nokia.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > > Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure > addresses for prefix options with the "A" bit set; the "L" bit is don't-care. > But, RFC 2461 (section 6.3.4) says that "a prefix information option with the > on-link flag set to zero conveys no information concerning on-link determination", > i.e., you can't tell whether the prefix is on/off link. But, if you configure an > address from a prefix option with the "L" bit set to zero and assign it to the > interface the RA arrived on, you are in effect declaring that at least one /128 > chunk of the prefix is on-link. But, I don't see any text in RFC 2461 that says > you can assume this. This is where I see the ambiguity. > Sure, that is what assigning an address to an interface means. Are you saying that you want to send datagrams that are destined to an address which is assigned to a local interface, to a router, just because the advertised prefix from which the address was derived had the "L" bit clear? If one were trying to implement the "L" bit to a fault, one might consider doing this but it is hard to see this being the first implementation choice that would occur to someone. Typically the act of assigning an address to a local interface implies node-local reachability. If there are implementations that don't assume this, I have never seen them. Tim Hartrick Mentat 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 Tue Feb 18 15:01:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IN1DQb026249; Tue, 18 Feb 2003 15:01:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1IN1D36026248; Tue, 18 Feb 2003 15:01:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1IN19Qb026241 for ; Tue, 18 Feb 2003 15:01:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1IN1JVL007904 for ; Tue, 18 Feb 2003 15:01:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00482 for ; Tue, 18 Feb 2003 16:01:13 -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 PAA07490; Tue, 18 Feb 2003 15:01:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1IN1Bm13560; Tue, 18 Feb 2003 15:01:11 -0800 X-mProtect: <200302182301> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRskF35; Tue, 18 Feb 2003 15:01:09 PST Message-ID: <3E52BBDB.8020608@iprg.nokia.com> Date: Tue, 18 Feb 2003 15:03:55 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Hartrick CC: narten@us.ibm.com, ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <200302182225.OAA03917@feller.mentat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Tim Hartrick wrote: > Sure, that is what assigning an address to an interface means. Are you saying > that you want to send datagrams that are destined to an address which is > assigned to a local interface, to a router, just because the advertised prefix > from which the address was derived had the "L" bit clear? No; I'm not saying that. I don't see any ambiguity in accepting the /128 resulting from address autoconfiguration as being "on-node"; i.e., it seems clear enough that packets sent by the node to the autoconfigured address should be looped back internally and not sent to a router. But, I still see it as ambiguous as to whether the /128 must be "on-link" with the interface the RA arrived on. Thanks, Fred ftemplin@iprg.nokia.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 18 19:12:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J3CLQb001897; Tue, 18 Feb 2003 19:12:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1J3CLSU001896; Tue, 18 Feb 2003 19:12:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J3CHQb001889 for ; Tue, 18 Feb 2003 19:12:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1J3CQVK028237 for ; Tue, 18 Feb 2003 19:12:26 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15518 for ; Tue, 18 Feb 2003 20:12:20 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 03:12:19 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 03:10:54 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 03:12:18 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 03:12:18 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 582AA15214; Wed, 19 Feb 2003 12:12:36 +0900 (JST) Date: Wed, 19 Feb 2003 12:12:25 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Fred L. Templin" Cc: Tim Hartrick , narten@us.ibm.com, ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: <3E52AC14.6040300@iprg.nokia.com> References: <200302182023.MAA03890@feller.mentat.com> <3E52AC14.6040300@iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Feb 2003 13:56:36 -0800, >>>>> "Fred L. Templin" said: >> I have myself been confused by the L bit in the past but I don't think >> there is anywhere near as much ambiguity here as you. And, if there is >> the node requirements document isn't the place to fix it. >> >>> I'm still of the opinion that some ambiguity exists. Namely, if a prefix >>> option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit) >>> NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK >>> to go ahead and configure an address from the (off-link) prefix as specified >>> in 5.5.3 d). But then, which link would one derive an interface identifier >>> from in order to form an address? (And, which interface would one assign >>> the address to?) I agree with Tim (and perhaps Thomas). I don't see any ambiguity in RFC 2461 and RFC 2462 on this point. >> It is correct to infer that one should configure an address from a prefix >> option with the A bit set and the L bit clear. Is it really necessary to >> spell out that the address should be configured on the interface on which >> the advertisement was received? What would justify making any other choice? > Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure > addresses for prefix options with the "A" bit set; the "L" bit is don't-care. > But, RFC 2461 (section 6.3.4) says that "a prefix information option with the > on-link flag set to zero conveys no information concerning on-link determination", > i.e., you can't tell whether the prefix is on/off link. But, if you configure an > address from a prefix option with the "L" bit set to zero and assign it to the > interface the RA arrived on, you are in effect declaring that at least one /128 > chunk of the prefix is on-link. But, I don't see any text in RFC 2461 that says > you can assume this. This is where I see the ambiguity. I don't see why we need to declare one /128 chunk. Perhaps you are just confused about a "on-link" prefix and a prefix (of the same length) as a base of address configuration. These two are, at least conceptually, orthogonal, which is very clear to me from the spec. 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 18 20:16:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J4G97f002313; Tue, 18 Feb 2003 20:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1J4G97s002312; Tue, 18 Feb 2003 20:16:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J4G67f002305 for ; Tue, 18 Feb 2003 20:16:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1J4GFVL007960 for ; Tue, 18 Feb 2003 20:16:15 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23077 for ; Tue, 18 Feb 2003 21:16:09 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:16:09 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:14:44 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:16:09 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:16:09 Z Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Tue, 18 Feb 2003 20:16:07 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C15@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: Content-class: urn:content-classes:message Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" thread-index: AcLXUWyUaNUUE2sFQC+dVIbd/GyFSAAehZkQ X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 From: "Michel Py" To: "Erik Nordmark" Cc: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1J4G67f002306 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > Erik Nordmark wrote: > Isn't there some other document which contains the IETF's > recommendation to IANA to hand out IPv6 prefixes to the RIRs? > It would be better if we can refer to a document (which might > evolve on its own) than explicitly state the range of > prefixes in this document because that means that should IANA > start handing out prefixes outside of 2000::/3 this document > will become inconsistent with reality. I guess I have not been clear enough. Proposed text: instead of: > RFC2374 was the definition of addresses for Format Prefix 001 > (2000::/3) which is formally made historic by this document. Although > as specified in [ARCH] IANA should limit the IPv6 unicast address > space to 2000::/3 for now, IANA might allocate unassigned parts of the > IPv6 address space to Global Unicast later. Please consider this: RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) which is formally made historic by this document. Although as specified in [ARCH] IANA should limit the IPv6 Global Unicast | address space to 2000::/3 for now, IANA might later delegate | currently unassigned parts of the IPv6 address space to the purpose | of Global Unicast as well. 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 Tue Feb 18 20:25:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J4PI7f002372; Tue, 18 Feb 2003 20:25:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1J4PIiQ002371; Tue, 18 Feb 2003 20:25:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1J4PE7f002364 for ; Tue, 18 Feb 2003 20:25:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1J4POVL009531 for ; Tue, 18 Feb 2003 20:25:24 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27083 for ; Tue, 18 Feb 2003 21:25:18 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:25:18 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:23:18 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:24:43 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 04:24:43 Z Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Tue, 18 Feb 2003 20:24:42 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C16@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: Content-class: urn:content-classes:message Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" thread-index: AcLXUcs7zjMTOnZxSwKJbqecy33lVQAe/zfw X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 From: "Michel Py" To: "Erik Nordmark" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1J4PF7f002365 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Erik Nordmark wrote: > I think the "SLA" field in 2374 has been replaced by the "subnet ID" > field in addr-arch-v3. It probably makes sense to make this clear by > adding a note e.g. > The SLA (subnet local aggregator) field in RFC 2374 remains in > function but with a different name in [ADDR-ARCH]; its new > name is "subnet ID". I like this. I was looking at some phrasing that would include the word "boundary" or "broder" but I can't formulate anything good. Food for the thought: might be a good idea to include a hint that the "subnet ID" bits are likely part of the scope of the site. 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 19 10:49:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1JInU7f016137; Wed, 19 Feb 2003 10:49:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1JInUBK016136; Wed, 19 Feb 2003 10:49:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1JInQ7f016129 for ; Wed, 19 Feb 2003 10:49:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1JInYVK022651 for ; Wed, 19 Feb 2003 10:49:34 -0800 (PST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19769 for ; Wed, 19 Feb 2003 11:49:29 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAK009WVKAGDS@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 11:49:28 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAK00GTSKAFXQ@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 19 Feb 2003 11:49:28 -0700 (MST) Date: Wed, 19 Feb 2003 10:49:26 -0800 From: Alain Durand Subject: playground status To: ipng@sunroof.eng.sun.com Message-id: <3E53D1B6.9040507@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are having some technical difficulties with the machine playground.sun.com, so the web server and the mail archives are not accessible at the moment, neither in IPv4 nor IPv6. We are doing our best to resolve this matter as soon as possible. In the meantime, please accept our apologies for the inconvenience. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 20 01:33:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1K9Xm7f022273; Thu, 20 Feb 2003 01:33:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1K9XmfB022272; Thu, 20 Feb 2003 01:33:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1K9Xi7f022265 for ; Thu, 20 Feb 2003 01:33:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1K9XrVL028445 for ; Thu, 20 Feb 2003 01:33:53 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21880 for ; Thu, 20 Feb 2003 01:33:47 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 09:33:45 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 09:33:44 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 09:33:44 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 09:33:43 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1K9Wta11788; Thu, 20 Feb 2003 11:32:56 +0200 Date: Thu, 20 Feb 2003 11:32:55 +0200 (EET) From: Pekka Savola To: "Alan E. Beard" cc: Kurt Erik Lindqvist , Tim Chown , , , Subject: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030214175244.P43282-100000@amneris.aebeard.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'll take one particular issue, and Cc: to multi6 as I believe it is a very important thing to consider. On Fri, 14 Feb 2003, Alan E. Beard wrote: > > > Most of the end-user-network managers among my clients now multihome, > > > and > > > will continue to require multihomed service in future. In every case > > > where the user's network is multihomed, the multiple independent > > > connections are seen as crucial for maintenance of high availability of > > > > [Kurtis:] > > I find this funny. A number of studies have shown that if this is what > > you are after, multihoming and BGP is the wrong way to go - but never > > mind. > > > Your comment may be true, but my clients are nonetheless unwilling to risk > the possibility of an extended network outage on a single ISP (while not > frequent, these events are far from unprecedented) rendering their online > customer-support environment unavailable for several hours, much less for > a day. Shorter outages (on the order of minutes in the single digits) are > tolerated, provided that such outages are infrequent. This is a very problematic approach IMO. Need more resiliency? Network outages unacceptable? The right place to fix this is the network service provider, period. Nothing else seems like a scalable approach. Consider a case when many companies _phone_ services would have been changed to VoIP. IP would be a critical service. Do the enterprises protect against failures by getting more ISP's? Unscalable. No, the ISP's _must_ get better. Pick one well when choosing them. When ISP's have SLA's, a lot of customers for which continued service is of utmost importance, the networks *will* work. There is just no other choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 minutes of network outage, things _will_ happen. It just seems the mentality in some networks is that network outages are ok, networks don't have to be designed with multiple connections, etc.etc. That must change if we want to build a mission-critical IP infrastructure. Instead of making every site try to deal with the problems themselves. This is my view as ISP and an end-user. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 07:06:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KF6K7f024823; Thu, 20 Feb 2003 07:06:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KF6Jjj024822; Thu, 20 Feb 2003 07:06:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KF6G7f024815 for ; Thu, 20 Feb 2003 07:06:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KF6OVL025921 for ; Thu, 20 Feb 2003 07:06:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01644 for ; Thu, 20 Feb 2003 08:06:17 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:06:12 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:06:11 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:06:11 Z Received: from sabre.ncc.catchcom.no (sabre.ncc.catchcom.no [193.75.1.130]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:06:10 Z Received: from [127.0.0.1] (localhost [127.0.0.1]) by sabre.ncc.catchcom.no (Postfix) with ESMTP id 245FA55E; Thu, 20 Feb 2003 16:06:08 +0100 (CET) Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] From: Lars Erik Gullerud To: Pekka Savola Cc: "Alan E. Beard" , Kurt Erik Lindqvist , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, randy@psg.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1045753567.81330.33.camel@sabre.ncc.catchcom.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Feb 2003 16:06:08 +0100 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-02-20 at 10:32, Pekka Savola wrote: > This is a very problematic approach IMO. > > Need more resiliency? Network outages unacceptable? > > The right place to fix this is the network service provider, period. > Nothing else seems like a scalable approach. In a perfect world I'm sure I'd agree with you. In real life however, the fact of the matter is that customers want multihoming, and it doesn't matter to the customers if that is a problematic approach that doesn't scale for the SPs. Doesn't even matter if it's technically the best solution for THEM, customers are not known for picking the best solutions, nor listening to their providers suggestions for better ones, half the time. And, the simple fact of the market economy is that what the customers want, the providers are going to sell. Making the IP backbones more resilient costs money. You get that money from your customers. You get the customers by selling them what they are asking for. What they are asking for is multihoming. If they can't multihome with IPv6, well, then they won't use IPv6 until they can. If the customers don't want to use IPv6, the providers won't spend the money to support it. ...and this is yet another rehash of a discussion that has already been had so many times by so many people that I'm sure we can just copy & paste from here on out. The fact of the matter is, whether it's the best approach or not, we need a solution for customers to multihome. So let's bring our attention back to that, shall we? /leg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 07:14:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KFEG7f025008; Thu, 20 Feb 2003 07:14:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KFEGnL025005; Thu, 20 Feb 2003 07:14: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.8+Sun/8.12.8) with ESMTP id h1KFEB7f024997 for ; Thu, 20 Feb 2003 07:14:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1KFECP22989; Thu, 20 Feb 2003 16:14:12 +0100 (MET) Date: Thu, 20 Feb 2003 16:10:27 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <963621801C6D3E4A9CF454A1972AE8F54C15@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 > Please consider this: > > RFC2374 was the definition of addresses for Format Prefix 001 > (2000::/3) which is formally made historic by this document. Although > as specified in [ARCH] IANA should limit the IPv6 Global Unicast > | address space to 2000::/3 for now, IANA might later delegate > | currently unassigned parts of the IPv6 address space to the purpose > | of Global Unicast as well. Works for me. 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 20 07:24:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KFOd7f025183; Thu, 20 Feb 2003 07:24:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KFOdTe025180; Thu, 20 Feb 2003 07:24:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KFOa7f025173 for ; Thu, 20 Feb 2003 07:24:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KFOhVL029966 for ; Thu, 20 Feb 2003 07:24:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25645 for ; Thu, 20 Feb 2003 07:24:38 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:24:36 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:24:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:24:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 15:24:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1KFO0b14663; Thu, 20 Feb 2003 17:24:00 +0200 Date: Thu, 20 Feb 2003 17:24:00 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030220112127.Q61596-100000@sequoia.muada.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 20 Feb 2003, Pekka Savola wrote: > > > > Your comment may be true, but my clients are nonetheless unwilling to risk > > > the possibility of an extended network outage on a single ISP (while not > > > frequent, these events are far from unprecedented) rendering their online > > > customer-support environment unavailable for several hours, much less for > > > a day. Shorter outages (on the order of minutes in the single digits) are > > > tolerated, provided that such outages are infrequent. > > > This is a very problematic approach IMO. > > > Need more resiliency? Network outages unacceptable? > > > The right place to fix this is the network service provider, period. > > Nothing else seems like a scalable approach. > > There is no technical reason why a single service provider network can > do better than a similar network that consists of several smaller > service provider networks. [...] Of course not -- but it's *much* easier. > > Consider a case when many companies _phone_ services would have been > > changed to VoIP. IP would be a critical service. Do the enterprises > > protect against failures by getting more ISP's? Unscalable. No, the > > ISP's _must_ get better. Pick one well when choosing them. > > We are _very_ far from a situation where even the best ISP provides a > service level that is better then the one you get from multihoming even > if you consider failover delays. In some cases, this may be better. In some others, not. It's not IMO necessary to get significantly better but "roughly equal". > > When ISP's have SLA's, a lot of customers for which continued service is > > of utmost importance, the networks *will* work. There is just no other > > choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 > > minutes of network outage, things _will_ happen. > > My experience with SLAs is that they are a marketing tool and job > security for bureaucrats. They don't make the worst case any better, > they only make the worst case slightly less frequent. > > (What makes you think this mobile phone will ring anyway? Speaking of > unreliable networks...) Some means of contacting will always exist, or the monitoring system of ISP's has developed so far the problems in the IP service are extremely rare. > And the single service provider thing doesn't scale anyway: the end > result would have to be a single global ISP. It does scale, pretty well actually. I'm not talking about your average neighborhood ISP's with 100 customers, though. Currently in DFZ, there are about 3500 (ONLY!) AS numbers which transit at least one other AS number. Even multiplying that with 10, we would not have a problem. > > It just seems the mentality in some networks is that network outages are > > ok, networks don't have to be designed with multiple connections, etc.etc. > > > That must change if we want to build a mission-critical IP infrastructure. > > Instead of making every site try to deal with the problems themselves. > > Has the end-to-end principle failed to teach us anything? Reliability > begins and ends in the end hosts. If each host is connected over two > service providers there are four possible paths the hosts can switch > between on a per-packet basis. Then the only problem becomes detecting > failure. The end hosts are in an excellent position to do this without > having to generate keepalive messages; a well designed protocol could > switch to an alternate path within a few round trip times when a path > failure occurs. Compare this to a solution where the site has two connections to the same ISP, and you're left with major ISP backbone failure or upstream failure (any relevant ISP's have only one upstream)? Doesn't sound that difficult to me, particularly as these problems affect the whole (or majority) of the ISP -- and hence, are fixed quickly. A solution without multi-connecting, ie. only one L1 connection to one ISP, is naturally out of question. > Multi6 has been gravitating towards multi-address multihoming solutions > for a while now, but unfortunately it seems impossible to move foward. Multi-address solutions solve certain problems well, but leave some unsolved. Coupling multi-addressing with multi-connecting, you have a very comprehensive solution, IMO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 08:27:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KGRo7f025696; Thu, 20 Feb 2003 08:27:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KGRotP025695; Thu, 20 Feb 2003 08:27:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KGRl7f025688 for ; Thu, 20 Feb 2003 08:27:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KGRsVK010215 for ; Thu, 20 Feb 2003 08:27:54 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14229 for ; Thu, 20 Feb 2003 09:27:49 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 16:27:39 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 16:24:55 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 16:24:55 Z Received: from srexchimc2.eng.emc.com (srexchimc2.eng.emc.com [168.159.40.71]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 16:24:54 Z Received: by srexchimc2.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 11:24:49 -0500 Message-Id: <33CE6457C7003A478381BCD0B584DEC502740E64@srmoon.eng.emc.com> From: "sasson, shuki" To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: IPv6 message size with OpenBSD. Is it a must that IPv6 packet len gth will be a multiply of 8? Date: Thu, 20 Feb 2003 11:24:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1KGRl7f025689 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, observing the code of OpenBSD and also trying it, I see that the code takes care that the IPv6 packet length will be a multiplication of 8. I read the IPv6 RFC 2460 and I didn't see ant restriction there that suggests that the IPv6 packet length should be a multiplication of 8. Does any of you have an idea why is that? Can I safely send IPv6 packet with a length that is not a multiplication of 8 and make a better use of the MTU? Example:: In a system where the MTU is 1500 the Ethernet packet sent in OpenBSD systems are 1510 instead of 1514 thus a loss of additional 4 bytes as a result. Your help is appreciated, Shuki Sasson Principal Engineer, Network Storage Group EMC² where information lives Phone: 508 305 8515 FaxNo: 508 435 8901 Pager: 877 919 0794 Email: sasson_shuki@emc.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 20 09:38:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KHcB7f026190; Thu, 20 Feb 2003 09:38:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KHcBni026189; Thu, 20 Feb 2003 09:38:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KHc77f026182 for ; Thu, 20 Feb 2003 09:38:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KHcEVK003105 for ; Thu, 20 Feb 2003 09:38:14 -0800 (PST) Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20445 for ; Thu, 20 Feb 2003 10:38:09 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MBQBNK5O@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 10:38:09 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM007Z4BNJ9Q@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 10:38:08 -0700 (MST) Date: Thu, 20 Feb 2003 09:38:07 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Message-id: <3E55127F.40306@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <963621801C6D3E4A9CF454A1972AE8F54C15@server2000.arneill-py.sacramento.ca.us> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > RFC2374 was the definition of addresses for Format Prefix 001 > (2000::/3) which is formally made historic by this document. Although > as specified in [ARCH] IANA should limit the IPv6 Global Unicast >| address space to 2000::/3 for now, IANA might later delegate >| currently unassigned parts of the IPv6 address space to the purpose >| of Global Unicast as well. > I'm not sure I like this last sentence. One could read it as IANA "might" later assign "currently unassigned parts of the IPv6 address space" for of something different than Global Unicast. Once could then fear that an implementor might then interpret that as "I'm going to hard code 2000::/3 as I do not know what is going to happen with the rest of the space". Suggested text: RFC2374 was the definition of addresses for Format Prefix 001 2000::/3) which is formally made historic by this document. Although, as specified in [ARCH], IANA should limit the IPv6 Global Unicast address space to 2000::/3 for now, the rest of the unassigned IPv6 address space should be treated as Global Unicast. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 20 10:57:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KIvR7f026774; Thu, 20 Feb 2003 10:57:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KIvQtS026773; Thu, 20 Feb 2003 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KIvN7f026766 for ; Thu, 20 Feb 2003 10:57:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KIvVVK001451 for ; Thu, 20 Feb 2003 10:57:31 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17417 for ; Thu, 20 Feb 2003 11:57:15 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 18:57:09 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 18:57:09 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 18:57:08 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 18:57:07 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KIv2JR009522; Thu, 20 Feb 2003 13:57:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13590; Thu, 20 Feb 2003 13:57:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 13:56:59 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reminder and note: there have been a few responses to this WG last call, but no explicit positive recommendations for advancement. Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 20 11:40:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJeU7f027303; Thu, 20 Feb 2003 11:40:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KJeU05027302; Thu, 20 Feb 2003 11:40:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJeP7f027295 for ; Thu, 20 Feb 2003 11:40:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KJeXVL019876 for ; Thu, 20 Feb 2003 11:40:33 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01969 for ; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MY2HBF2Y@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM007HQHBECA@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 12:40:27 -0700 (MST) Date: Thu, 20 Feb 2003 11:40:26 -0800 From: Alain Durand Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3E552F2A.2090302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From a quick look at the draft: 4. Domain Name Server option The Domain Name Server option provides a list of one or more IP addresses of DNS servers to which a client's DNS resolver MAY send DNS queries [2]. The DNS servers are listed in the order of preference for use by the client resolver. The format of the Domain Name Server option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? How would the DHCP client knows? From the width of the boxes, one could think it it is v4 addresses, but from the height (4 lines!), one could think it is actually v6 addresses. My points are: - the spec is unclear if those addresses are v4 or v6 - it may makes sense to actually mix both type in an announcement, for example say: try this v6 address, if it does not work, try this v4 one. Then each DNS server entry should have both the actual address and its family. - Alain. Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last > call, but no explicit positive recommendations for advancement. > Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply > with comments. If you recommend the document for advancement without > revision, please respond with a quick acknowledgment. No response > will be interpreted as a lack of support for advancing the document. > > ----- > > This message announces a WG last call on "DNS Configuration options > for DHCPv6" . The last > call will conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext > WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List > option. This document is being considered for Proposed Standard as an > extension to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > > > - 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 Thu Feb 20 11:54:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJsP7f027409; Thu, 20 Feb 2003 11:54:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KJsP3c027408; Thu, 20 Feb 2003 11:54:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJsM7f027401 for ; Thu, 20 Feb 2003 11:54:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KJsTVL024047 for ; Thu, 20 Feb 2003 11:54:29 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16265 for ; Thu, 20 Feb 2003 12:54:24 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:54:23 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:54:22 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:54:22 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:54:22 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1KJrlg16575; Thu, 20 Feb 2003 21:53:47 +0200 Date: Thu, 20 Feb 2003 21:53:47 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030220195703.M61596-100000@sequoia.muada.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 20 Feb 2003, Pekka Savola wrote: > > > We are _very_ far from a situation where even the best ISP provides a > > > service level that is better then the one you get from multihoming even > > > if you consider failover delays. > > > In some cases, this may be better. In some others, not. > > > It's not IMO necessary to get significantly better but "roughly equal". > > Don't forget that failover is just one of the benefits of multihoming. > Two important others are protection against losing service when ISPs > go out of business Sure, independence is another issue -- not related to ISP failures, and there are ways to protect against this. > and more optimal traffic flow. I agree, but other than really simple traffic flow balancing (read: multiple addresses) is a difficult thing to do, and people don't often really do it. > > > And the single service provider thing doesn't scale anyway: the end > > > result would have to be a single global ISP. > > > It does scale, pretty well actually. I'm not talking about your average > > neighborhood ISP's with 100 customers, though. Currently in DFZ, there > > are about 3500 (ONLY!) AS numbers which transit at least one other AS > > number. > > I don't see your point. What you were saying is that using a single > reliable ISP would be better than multihoming. Considering the tradeoffs, yes. > Now obviously an ISP can > only control the QoS parameters inside its own network so if you want to > do reliable and high quality VoIP you need to use the same ISP > end-to-end. In other words: just one ISP. This seems like a ridiculous argument or I'm missing something. You could just use VoIP up to the ISP, have ISP's coordinate the parameters (if you need any), etc. This is no different than multihomed scenario. > > > Has the end-to-end principle failed to teach us anything? Reliability > > > begins and ends in the end hosts. If each host is connected over two > > > service providers there are four possible paths the hosts can switch > > > between on a per-packet basis. Then the only problem becomes detecting > > > failure. The end hosts are in an excellent position to do this without > > > having to generate keepalive messages; a well designed protocol could > > > switch to an alternate path within a few round trip times when a path > > > failure occurs. > > > Compare this to a solution where the site has two connections to the same > > ISP, and you're left with major ISP backbone failure or upstream failure > > (any relevant ISP's have only one upstream)? > > So ISPs get to multihome but not end-users? Yes. > There are many ways in which an ISP network can fail, as the large scale > Worldcom and AT&T outages six months ago illustrate. I'm not aware of the case, so I can't really comment. Pointers? > More common is the > situation that an ISP network has trouble reaching a certain destination > because the only link to that destination has failed (which in itself > may not be their fault) or there is congestion somewhere. This seems no different than the case when using BGP site multihoming -- unless you want the fine-tune your policy per destination -- a non-starter. > And don't > forget maintenance windows. No real ISP has maintenance windows that seriously affect all communications at once. > > A solution without multi-connecting, ie. only one L1 connection to one > > ISP, is naturally out of question. > > Ok, so why is multihoming to a single ISP better than multihoming to > several ISPs? Fewer tradeoffs: you can protect against most failure modes, while not having to hae AS, your own IP addresses etc -- that is, it doesn't require bloating the DFZ! > > > Multi6 has been gravitating towards multi-address multihoming solutions > > > for a while now, but unfortunately it seems impossible to move foward. > > > Multi-address solutions solve certain problems well, but leave some > > unsolved. > > Like what? Solves: operator independence Doesn't solve: connection survivability, short-term failures, more than basic TE [mostly a non-issue IMO] Mixing multiconnecting to one ISP and having a backup to the second one gives you mostly everything. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 11:55:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJtN7f027435; Thu, 20 Feb 2003 11:55:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KJtNwU027434; Thu, 20 Feb 2003 11:55:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KJtJ7f027427 for ; Thu, 20 Feb 2003 11:55:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KJtRVK019782 for ; Thu, 20 Feb 2003 11:55:27 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16879 for ; Thu, 20 Feb 2003 12:55:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:55:21 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:53:52 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:55:21 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 19:55:20 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KJtEJR013584; Thu, 20 Feb 2003 14:55:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18996; Thu, 20 Feb 2003 14:55:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030220143854.03e69358@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 14:55:11 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <200302101927.h1AJRdu16843@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your feedback, Peter; my comments in line... - Ralph At 08:27 PM 2/10/2003 +0100, Peter Koch wrote: > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List > > > This document uses terminology specific to IPv6 and DHCPv6 as defined > > in section "Terminology" of the DHCP specification. > >Might want to add an explicit normative reference here? OK. > > 4. Domain Name Server option > > > > The Domain Name Server option provides a list of one or more IP > > addresses of DNS servers to which a client's DNS resolver MAY send > > >From a purist's point of view I'm tempted to say that you're not really > looking >for a DNS server here but instead for a (list of) recursive resolvers. Should this sentence read (I'm not a DNS purist!): The Domain Name Server option provides a list of one or more IP addresses of DNS recursive resolvers to which a client's DNS resolver MAY send DNS queries [2]. > > DNS-server: IP address of DNS server (change to "DNS recursive resolver"?) >I did not follow the DHCPv6 effort too close, so I must admit not knowing >the usual "culture", but wouldn't it be better to say IPv6 address here? Yes; also see follow up by Alain Durand. > > A server sends a Domain Search List option to the DHCP client to > > specify the domain search list the client is to use when resolving > > hostnames with DNS. This option does not apply to other name > > resolution mechanisms. > >The draft does not say for which kind of domain names the client is expected >to process the list, i.e. one-label names only, n-label names (how to >communicate the 'n', aka 'ndots', then?) or whether this is left to the >application(s). > > > Because the Domain Search List option may be used to spoof DNS name > > resolution in a way that cannot be detected by DNS security > > mechanisms like DNSSEC [5], DHCP clients and servers MUST use > >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it >wouldn't be able to detect spoofing. If, however, you want to say that >using domain names in the search list you don't control is a dangerous >thing, that could be emphazised by a reference to RFC 1535. The idea here (note that I'm not a DNSSEC expert, either) is that a search list that the host doesn't control might still pass DNSSEC authentication while yielding unexpected results. I would be happy to hear that DNSSEC can prevent the problem and would be willing to follow your suggestion and replace the reference to DNSSEC with a more general reference to untrusted search lists. > > authenticated DHCP when a Domain Search List option is included in a > > DHCP message. > >Why is this a MUST while there's a SHOULD only for the server option? They probably both should have the same level of requirement; I would think SHOULD would be sufficient for both. >-Peter > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 12:17:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KKHa7f027985; Thu, 20 Feb 2003 12:17:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KKHafC027984; Thu, 20 Feb 2003 12:17:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KKHW7f027977 for ; Thu, 20 Feb 2003 12:17:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KKHeVL002160 for ; Thu, 20 Feb 2003 12:17:40 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07202 for ; Thu, 20 Feb 2003 13:17:34 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:17:33 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:17:33 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:17:33 Z Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:17:32 Z Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KKEoN12781; Thu, 20 Feb 2003 14:14:50 -0600 (CST) Date: Thu, 20 Feb 2003 13:17:26 -0700 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Message-Id: <5448A21C-4510-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I thought I had said that I thought it should go ahead, but maybe not explicitly. I would like to see this draft advance. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 12:22:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KKMC7f028161; Thu, 20 Feb 2003 12:22:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1KKMB0b028158; Thu, 20 Feb 2003 12:22:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1KKM77f028144 for ; Thu, 20 Feb 2003 12:22:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1KKMFVL004543 for ; Thu, 20 Feb 2003 12:22:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00299 for ; Thu, 20 Feb 2003 12:22:09 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:11:55 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:11:52 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:11:52 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 20:03:54 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KK3oJR014151; Thu, 20 Feb 2003 15:03:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19859; Thu, 20 Feb 2003 15:03:49 -0500 (EST) Message-Id: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 15:03:44 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3E552F2A.2090302@sun.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, If it's unclear, then we should edit the document to explicitly identify the addresses as IPv6 addresses. This option is intended to return IPv6 configuration information. IPv4 addresses for DNS resolvers should be provided through DHCPv4... - Ralph At 11:40 AM 2/20/2003 -0800, Alain Durand wrote: > From a quick look at the draft: > >4. Domain Name Server option > > The Domain Name Server option provides a list of one or more IP > addresses of DNS servers to which a client's DNS resolver MAY send > DNS queries [2]. The DNS servers are listed in the order of > preference for use by the client resolver. > > The format of the Domain Name Server option is: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_DNS_SERVERS | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? >How would the DHCP client knows? > From the width of the boxes, one could think it it is v4 addresses, >but from the height (4 lines!), one could think it is actually v6 addresses. > >My points are: >- the spec is unclear if those addresses are v4 or v6 >- it may makes sense to actually mix both type in an announcement, > for example say: try this v6 address, if it does not work, try this v4 one. > Then each DNS server entry should have both the actual address and its > family. > > - Alain. > > >Ralph Droms wrote: > >>Reminder and note: there have been a few responses to this WG last call, >>but no explicit positive recommendations for advancement. >>Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with >>comments. If you recommend the document for advancement without >>revision, please respond with a quick acknowledgment. No response will >>be interpreted as a lack of support for advancing the document. >> >>----- >> >>This message announces a WG last call on "DNS Configuration options for >>DHCPv6" . The last call will >>conclude on Friday, 2/21. >> >>Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. >> >>draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for >>DHCPv6: the Domain Name Server option and the Domain Search List >>option. This document is being considered for Proposed Standard as an >>extension to the base DHCPv6 specification, and is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt >> >>- 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 >>-------------------------------------------------------------------- > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 16:09:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L09e7f000538; Thu, 20 Feb 2003 16:09:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L09eWU000537; Thu, 20 Feb 2003 16:09:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L09Z7f000527 for ; Thu, 20 Feb 2003 16:09:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L09hVK020799 for ; Thu, 20 Feb 2003 16:09:43 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29340 for ; Thu, 20 Feb 2003 17:09:38 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MGWTS15O@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 17:09:38 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM0062DTS0W0@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 17:09:37 -0700 (MST) Date: Thu, 20 Feb 2003 16:10:44 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > Alain, > > If it's unclear, then we should edit the document to explicitly > identify the addresses as IPv6 addresses. > > This option is intended to return IPv6 configuration information. > IPv4 addresses for DNS resolvers should be provided through DHCPv4... ??? Why so? This would be the equivalent to say: "If queried using IPv6, DNS will return AAAA and if queried using IPv4, it will return A". Now, let's say that this is the case for DHCP, what should a node that act both as a DHCPv4 and DHCPv6 client do when it will be returned two lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via DHCPv6. Which one should take priority? - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 20 19:55:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L3ta7f001220; Thu, 20 Feb 2003 19:55:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L3tadf001219; Thu, 20 Feb 2003 19:55:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L3tX7f001212 for ; Thu, 20 Feb 2003 19:55:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L3teVL022000 for ; Thu, 20 Feb 2003 19:55:40 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21708 for ; Thu, 20 Feb 2003 19:55:35 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 03:55:34 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 03:54:04 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 03:55:34 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 03:55:33 Z Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Thu, 20 Feb 2003 19:55:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C26@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLZBtYaoJS4EtcRR02MxV2phKYigAAVQOPA From: "Michel Py" To: "Alain Durand" Cc: "Erik Nordmark" , "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1L3tX7f001213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, > Alain Durand > RFC2374 was the definition of addresses for Format Prefix > 001 (2000::/3) which is formally made historic by this document. > Although, as specified in [ARCH], IANA should limit the IPv6 > Global Unicast address space to 2000::/3 for now, the rest of > the unassigned IPv6 address space should be treated as Global > Unicast. This is dangerous, IMHO. What we do not want is developers hardcoding 2000::/3 in their implementations; we don't know what the needs of tomorrow are though. If someone invents a killer app that requires allocating a /3 to multicast or anycast, your text would have to be revised. There is indeed a difference between unassigned and treated as Global Unicast. Currently unassigned parts of the IPv6 space should not be treated as anything. 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 20 22:20:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6Kg7f002478; Thu, 20 Feb 2003 22:20:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L6Kg8i002477; Thu, 20 Feb 2003 22:20:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6Kb7f002470 for ; Thu, 20 Feb 2003 22:20:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L6KjVL018238 for ; Thu, 20 Feb 2003 22:20:45 -0800 (PST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19239 for ; Thu, 20 Feb 2003 23:20:40 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAN005GXAUN0E@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 23:18:24 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAN006LHAULVX@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 23:18:23 -0700 (MST) Date: Thu, 20 Feb 2003 22:19:28 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-reply-to: <963621801C6D3E4A9CF454A1972AE8F54C26@server2000.arneill-py.sacramento.ca.us> To: Michel Py Cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Message-id: <6EBC3455-4564-11D7-A383-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oddly enough, from the same premises we arrived to opposite conclusions! If you leave the space out of 2000::/3 as 'unassigned' and I'm an implementor, I may put special code when sending a unicast packet to make sure that SRC & DST addresses are within the valid range... - Alain. On Thursday, February 20, 2003, at 07:55 PM, Michel Py wrote: > Alain, > >> Alain Durand >> RFC2374 was the definition of addresses for Format Prefix >> 001 (2000::/3) which is formally made historic by this document. >> Although, as specified in [ARCH], IANA should limit the IPv6 >> Global Unicast address space to 2000::/3 for now, the rest of >> the unassigned IPv6 address space should be treated as Global >> Unicast. > > This is dangerous, IMHO. What we do not want is developers hardcoding > 2000::/3 in their implementations; we don't know what the needs of > tomorrow are though. If someone invents a killer app that requires > allocating a /3 to multicast or anycast, your text would have to be > revised. There is indeed a difference between unassigned and treated as > Global Unicast. Currently unassigned parts of the IPv6 space should not > be treated as anything. > > 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 Thu Feb 20 22:26:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6Q27f002582; Thu, 20 Feb 2003 22:26:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L6Q2uX002581; Thu, 20 Feb 2003 22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6Px7f002574 for ; Thu, 20 Feb 2003 22:25:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L6Q6VL019242 for ; Thu, 20 Feb 2003 22:26:06 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21821 for ; Thu, 20 Feb 2003 23:26:01 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 06:26:00 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP; Fri, 21 Feb 2003 06:26:00 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Fri, 21 Feb 2003 06:26:00 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP; Fri, 21 Feb 2003 06:25:59 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L6Pvm20135; Fri, 21 Feb 2003 08:25:57 +0200 Date: Fri, 21 Feb 2003 08:25:57 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt 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, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > If it's unclear, then we should edit the document to explicitly > > identify the addresses as IPv6 addresses. > > > > This option is intended to return IPv6 configuration information. > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... I symphatize with this -- there are some uses to have DHCPv6 return IPv4 addresses too -- but the result would just make the dnsconfig option more complex for little benefit. Let's face it: if you deploy DHCPv6, you really should have long since deployed IPv6-enabled nameservers too. So, I think clarifying the scope to do only IPv6 seems like the best option by far. > Now, let's say that this is the case for DHCP, what should a node that > act both as a DHCPv4 and DHCPv6 client do when it will be returned two > lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > DHCPv6. Which one should take priority? Implementation decision, but I guess typically the results of the latest query take precedence. I don't see a problem here, myself. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 22:39:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6dZ7f003033; Thu, 20 Feb 2003 22:39:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L6dZO2003032; Thu, 20 Feb 2003 22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6dV7f003025 for ; Thu, 20 Feb 2003 22:39:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L6ddVL021739 for ; Thu, 20 Feb 2003 22:39:39 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27876 for ; Thu, 20 Feb 2003 23:39:33 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAN005OKBS0TC@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAN006WTBRYVU@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Date: Thu, 20 Feb 2003 22:39:29 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>> If it's unclear, then we should edit the document to explicitly >>> identify the addresses as IPv6 addresses. >>> >>> This option is intended to return IPv6 configuration information. >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return > IPv4 > addresses too -- but the result would just make the dnsconfig option > more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Some may scream at this idea, but couldn't we pass an IPv4-mapped address in there? The DHCPv6 client could recognize this special format to mean this is actually a v4 address? > >> Now, let's say that this is the case for DHCP, what should a node that >> act both as a DHCPv4 and DHCPv6 client do when it will be returned two >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >> DHCPv6. Which one should take priority? > > Implementation decision, but I guess typically the results of the > latest query take precedence. I don't see a problem here, myself. Unpredictable behavior. Difficult to debug. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 20 22:53:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6rm7f003309; Thu, 20 Feb 2003 22:53:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L6rmrq003308; Thu, 20 Feb 2003 22:53:48 -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.8+Sun/8.12.8) with ESMTP id h1L6rh7f003301 for ; Thu, 20 Feb 2003 22:53:44 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1L6rhP00363; Fri, 21 Feb 2003 07:53:43 +0100 (MET) Date: Thu, 20 Feb 2003 23:47:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Summary: Reason for the explicit link-layer address options in ND? To: SEND WG , Pekka Nikander Cc: IPV6 WG , Jim.Bound@hp.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: "Your message with ID" <3E4B7905.9080706@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Finally, the reasons for not peeking at the actual > link layer addresses used in the link layer frame can > be summarized as follows: > > 6. Separation of function > > This again follows the architectural principle. > Especially, it was viewed that checking the > link-layer addresses is a link layer function, > and it should be separate from the IP layer. > > Is that all or am I missing something? Or is there > something above that doesn't belong there? I recall there was also a feeling that since ARP provides the same separation (ARP doesn't use the addresses in the link-layer frame) it would be a bit too creative to remove it. I think the separation in ARP has, if not helped, given more flexibility e.g. when bridging between different 802 media with different bit order in the header (e.g. Ethernet to Token ring or FDDI). Also, I think it might have helped for media that doesn't have actual link-layer addresses but instead just a local DLCI - where the DLCIs each end sees is different. In that case there isn't an address in the datalink header you can use. 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 20 22:55:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6tI7f003347; Thu, 20 Feb 2003 22:55:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L6tHj5003344; Thu, 20 Feb 2003 22:55:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L6tE7f003336 for ; Thu, 20 Feb 2003 22:55:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L6tMVL024454 for ; Thu, 20 Feb 2003 22:55:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23762 for ; Thu, 20 Feb 2003 23:55:16 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 06:55:16 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Fri, 21 Feb 2003 06:55:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Fri, 21 Feb 2003 06:55:15 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP; Fri, 21 Feb 2003 06:55:15 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L6tDw20364; Fri, 21 Feb 2003 08:55:13 +0200 Date: Fri, 21 Feb 2003 08:55:13 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return > > IPv4 > > addresses too -- but the result would just make the dnsconfig option > > more > > complex for little benefit. Let's face it: if you deploy DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > Some may scream at this idea, but couldn't we pass an IPv4-mapped address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? That is certainly an idea, but I don't like passing around mapped addresses if it can be avoided. Anything which requires special code in DHCPv6 seems like a bad idea. Of course, if the mapped address is pushed in your /etc/resolv.conf and your resolver understands that.... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 20 23:15:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L7FM7f003738; Thu, 20 Feb 2003 23:15:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L7FMjG003737; Thu, 20 Feb 2003 23:15:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L7FJ7f003730 for ; Thu, 20 Feb 2003 23:15:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L7FQVL027936 for ; Thu, 20 Feb 2003 23:15:26 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13915 for ; Fri, 21 Feb 2003 00:15:21 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 07:14:49 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Fri, 21 Feb 2003 07:13:18 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 21 Feb 2003 07:14:48 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP; Fri, 21 Feb 2003 07:14:48 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L7Eku20493; Fri, 21 Feb 2003 09:14:46 +0200 Date: Fri, 21 Feb 2003 09:14:46 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: a few comments on anycast mechanisms 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 Hello, Sorry for the delay in responding. On Tue, 18 Feb 2003, Erik Nordmark wrote: > > 1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using > > MLD) -- May 2002. > > > > ==> basically the MLD protocol is used to signal anycast joins/leaves. > > However, critical part which seems to be missing here is "interactions of > > anycast-MLD with routing", as with multicast. > > > > There are a _lot_ of issues there, especially if one anycast address can > > have joins from across multiple routers. Even more so if from across > > multiple sites/AS's, or more specifically (with some terminology pixie > > dust) an IGP/iBGP area -- a region where propagating host routes is > > acceptable. But I'd recommend sticking to a site, the rest is way too > > difficult for now. > > I agree that there are issues like that. But those issues > are independent of the protocol mechanism (MLD, RIPng, OSPFv3, ISIS, > BGP - gawk!) that is used to carry the routes from the host to the router. > > The authorization independently of the protocol. Totally agree here: the crux of the problem is the authorization (and AFAICS, it is not a small problem -- contrary to the multicast model). > > Thus by far the easiest way to enable anycast on hosts seems to be a > > requirement for them to participate in a routing protocol. Something like > > BGP is good for this (not ideal: too much weight). Simpler protocols can > > of course also be used; the most important thing is to pick one which > > allows your neighbor(s) to filter out any advertisements excluding the > > anycast addresses(es) -- so that you can't hose the routing to other than > > the anycast address(es) itself even in the worst case scenario. > > BGP??? Yes! > I think there is some operational experience that configuring a routing > protocol on the hosts for the sole purpose of announcing one or more > (anycast) source routes adds a lot of complexity. Not only does the > host need to implement a routing protocol which interoperates with > what the routers run, you also need to prevent the host from ever > being used for forwarding. If the host is multi-interfaced this might > be quite tricky and error prone. > > Thus having a separate host-to-router protocol with limited functionality > seems to make sense to me. I seem to have a different opinion. To me, configuring BGP is very simple operation: you can be sure how it works, and the basic configuration is easy to do. On the other hand, I'm very worried about specifying a host-router protocol, as it is a new protocol -- contrary to working operational practise -- and has a number of difficult issue to tackle with, most important of them perhaps the security/authorization and interaction with the routing protocols. I fail to see an issue with multi-interfaced hosts: all implementations I know have an explicit toggle to disable/enable packet forwarding between interfaces ("routing"). > > To prevent such attacks, it is expected that routers will employ > > some filtering mechanism when receiving a Report message containing > > a non-multicast address. For example, one policy might be to deny > > all anycast joins except those that match a configured list of > > (source address, anycast address) pairs. > > > > ==> the problems with such a measure seems to be that: > > 1) MLD message does not signify other than link-local addresses AFAIR > > 2) some addresses are easily spoofed. > > > > Of course, to be complete, some "reverse-path verification" for addresses, > > if routable unicast, would have to be done. > > How would reverse-path help with the authorization issue (which node can > "join" e.g. the "sun-ntp-server" anycast address? I'm making the assumption that either: 1) anycast addresses are defined from the same subnet as the anycast nodes reside in, or 2) authorization of anycast address joining must be completely manually configured In the first case, consider the subnet 2001:db8::/64. Two nodes have unicast addresses 2001:db8::1 and 2001:db8::2 there. They want to participate in anycast group 2001:db8::53. Now, the router would check the unicast route it has to "2001:db8::53". That points to interface with 2001:db8::/64. In consequence, it only allows anycast joins to the group "2001:db8::53" from 2001:db8::/64. But of course, this case of anycast usage is not all that interesting I think -- most probably want to have the anycast nodes deployed on different subnets. Another (and additional) variant of this is performing a uRPF check on the unicast address. That is, if an anycast group join is said to come from 2001:db8::3, check that it arrived from the interface where the route to that destination points to. > > - the high number of packets exchanged before commencing with real TCP > > traffic > > And the alternative is? Possibly some TCP modification. I'm not sure if there are others. > > - the changes to TCP to run this operation at the reception of a specific > > TCP SYN (perhaps this happens with MIPv6, but my impression has been that > > in most cases, return routability is executed based on MN's own desire to > > do send packets, not respond to some of them) > > > > - the different model of address ownership model; this seem the most > > important. MIPv6 RR is used to prove that the MN has the right to use > > certain care-of/home address. These are network-topology -independent, in > > a sense; a part of an autoconfigured/statefully-configured prefix, freely > > configurable by anyone on the link(s). > > > > Anycast is different: there the right target to ask for permission to > > certify this binding would appear to be the routing system, or someone in > > charge of specifying the -pair. > > I think that is the local problem - the first-hop router next to the anycast > server. And that needs to be solved with some form of access control list. That isn't a big problem, I guess -- if anycast servers are deployed behind a single router. Otherwise it gets hairier.. > > 3) that's it. > > > > My own, very raw idea for anycast + TCP: a new ICMP message, including the > > seq number (or equivalent protocol-specific information) of the > > just-received TCP SYN, indicating the unicast address which should be used > > instead of the included anycast address. > > > > Of course, this brings up the problem of easily-guessable TCP seq numbers. > > This could be mostly remedied by requiring (I wonder if this kind of > > requirement would be sane..) that TCP implementations check their SYN_SENT > > state tables that the packet has actually been sent to the the destination > > very recently -- thus the window where a timing attack could be done would > > be almost eliminated. > > And you have the option of the target to bomb a victim by saying "send your > packets to Alice" even though Alice is not part of the anycast group. > The use of RR prevents this, as well as provides something stronger than > the TCP sequence number from a guessing perspective. Yes, but RR does not come without a cost. TCP sequence number, coupled with a very short window and a limited number of tries, seems rather safe even if TCP seqno would have not base itself on a strong PRNG. > > As an option, if the initiator would not believe this binding, some > > stronger mechanisms could be applied (source address comparison, which is > > not really valid except if we apply some new requiremens for anycast usage > > -- like that to be used like this, the addresses must all be from the same > > /64, /48, /32 or whatever *); RR tests; etc.). > > > > Of course, all of this would appear to be moot if something like IPsec was > > used between the end-points. > > I must have missed the document which specifies how IPsec works with anycast > addresses :-) "Works" is relative :-). I was referring to the process of sending an initiation of communications to the anycast address, and _then_ enabling ESP-protected IPsec communication to the unicast address -- ie, no problem there. Of course, there may be a slight problem of having keys to all the unicast addresses behind the anycast address, but I don't see that as a huge problem with IPsec keying problems as is. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 00:47:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L8ll7f004373; Fri, 21 Feb 2003 00:47:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L8ll18004372; Fri, 21 Feb 2003 00:47:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L8lh7f004364 for ; Fri, 21 Feb 2003 00:47:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L8lqVK021422 for ; Fri, 21 Feb 2003 00:47:52 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23355 for ; Fri, 21 Feb 2003 01:47:38 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 08:47:34 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 08:47:27 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 08:47:27 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 08:47:26 Z Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Fri, 21 Feb 2003 00:47:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C27@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLZcaLL3AK243JFRP+bQ57Ni1QWWAADt/Zw From: "Michel Py" To: "Alain Durand" Cc: "Erik Nordmark" , "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1L8li7f004365 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, > Alain Durand wrote: > Oddly enough, from the same premises we arrived to opposite > conclusions! If you leave the space out of 2000::/3 as > 'unassigned' and I'm an implementor, I may put special > code when sending a Unicast packet to make sure that SRC & > DST addresses are within the valid range... > Once could then fear that an implementor might then interpret > that as "I'm going to hard code 2000::/3 as I do not know what > is going to happen with the rest of the space". I don't see how one would reach that conclusion without figuring out that it would be a good way to shoot self in the foot later on. Besides, [ARCH] is clear enough about this topic: > [ARCH] > 2.4 Address Type Identification > The type of an IPv6 address is identified by the high-order bits of > the address, as follows: > 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) <<<=== already says this. I am not hot about putting "unassigned IPv6 address space should be treated as Global Unicast" in this text. It is clear that the end result will be the same for now, but what we really want is implementers *not* to hardcode anything and your text goes too far IMHO. Although I agree that treating unassigned space as Global Unicast is a good idea, there is no need to put it in the text. The rationale of this is that what we are contemplating now is that this doc will not make it to the standards track. It is permitted to think that future revisions of [ARCH] might change section 2.4 and it is possible (although not probable) that we might require later that unassigned space be treated as Multicast (or whatever). The point here is that if we need to modify [ARCH] later on, we don't want to have to modify this doc to sync it with the new [ARCH]. Your point is valid though, what about this: Proposed text: RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) which is formally made historic by this document. Although as specified in [ARCH] IANA should limit the IPv6 Global Unicast address space to 2000::/3 for now, IANA might later delegate currently unassigned parts of the IPv6 address space to the purpose of Global Unicast as well. Implementations MUST NOT make address range checks for Global Unicast addresses. (This would require to re-introduce a reference to RFC 2119 normative language, could be replaced by "must not" discretion of the authors). 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 21 00:51:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L8pH7f004457; Fri, 21 Feb 2003 00:51:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L8pHBE004456; Fri, 21 Feb 2003 00:51:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L8pD7f004446 for ; Fri, 21 Feb 2003 00:51:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L8pLVK022823 for ; Fri, 21 Feb 2003 00:51:22 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06312 for ; Fri, 21 Feb 2003 01:51:16 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAN0055YHXFTC@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 01:51:16 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAN0069PHXEW0@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 01:51:15 -0700 (MST) Date: Fri, 21 Feb 2003 00:52:20 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" In-reply-to: <963621801C6D3E4A9CF454A1972AE8F54C27@server2000.arneill-py.sacramento.ca.us> To: Michel Py Cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, February 21, 2003, at 12:47 AM, Michel Py wrote: > Alain, > Your point is valid though, what about this: > > Proposed text: > RFC2374 was the definition of addresses for Format Prefix 001 > (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 Global Unicast address space to > 2000::/3 for now, IANA might later delegate currently unassigned parts > of the IPv6 address space to the purpose of Global Unicast as well. > Implementations MUST NOT make address range checks for Global Unicast > addresses. Fine by me. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 21 01:08:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L98B7f004767; Fri, 21 Feb 2003 01:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L98Bqj004766; Fri, 21 Feb 2003 01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L9857f004753 for ; Fri, 21 Feb 2003 01:08:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L98EVK026111 for ; Fri, 21 Feb 2003 01:08:14 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26646 for ; Fri, 21 Feb 2003 02:08:08 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 09:08:08 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 09:06:35 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 09:08:05 Z Received: from p-mail2 ([193.49.124.32] [193.49.124.32]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 09:08:05 Z Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by 192.144.74.32 with InterScan Messaging Security Suite; Fri, 21 Feb 2003 10:12:03 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Feb 2003 10:07:14 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 10:07:13 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLZdJ2qzsJy1hb2SAuoytmUjyAg6AAEmgEg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Alain Durand" , "Pekka Savola" Cc: "Ralph Droms" , , , X-OriginalArrivalTime: 21 Feb 2003 09:07:14.0493 (UTC) FILETIME=[A01E86D0:01C2D988] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1L9867f004754 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > De : Alain Durand [mailto:Alain.Durand@Sun.COM] > > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided > through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return > > IPv4 > > addresses too -- but the result would just make the > dnsconfig option > > more > > complex for little benefit. Let's face it: if you deploy > DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > > Some may scream at this idea, but couldn't we pass an IPv4-mapped > address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? > I feel ill at ease with such a solution. How your DHCPv6 client, running a node, is aware that there is an IPv4 stack enable on that same node ? If it is not, v4-mapped addresses could be harmfull, couldn't they ? > > > > >> Now, let's say that this is the case for DHCP, what should > a node that > >> act both as a DHCPv4 and DHCPv6 client do when it will be > returned two > >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > >> DHCPv6. Which one should take priority? > > > > Implementation decision, but I guess typically the results of the > > latest query take precedence. I don't see a problem here, myself. > > Unpredictable behavior. Difficult to debug. > > - Alain. > Good remark! I understand the point/issue if IPv6 provider is not the same as IPv4 one. By that way the node may not have the same global vision of the Domain Name System! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 01:30:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L9U77f005529; Fri, 21 Feb 2003 01:30:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1L9U7Gs005528; Fri, 21 Feb 2003 01:30:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1L9U37f005520 for ; Fri, 21 Feb 2003 01:30:04 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1L9UCVK000394 for ; Fri, 21 Feb 2003 01:30:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02481 for ; Fri, 21 Feb 2003 01:30:07 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 09:30:00 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Fri, 21 Feb 2003 09:28:27 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 21 Feb 2003 09:29:57 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP; Fri, 21 Feb 2003 09:29:56 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L9Tso21144; Fri, 21 Feb 2003 11:29:54 +0200 Date: Fri, 21 Feb 2003 11:29:54 +0200 (EET) From: Pekka Savola To: BELOEIL Luc FTRD/DMI/CAE cc: Alain Durand , Ralph Droms , , , Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt 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, 21 Feb 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > Implementation decision, but I guess typically the results of the > > > latest query take precedence. I don't see a problem here, myself. > > > > Unpredictable behavior. Difficult to debug. > > > > - Alain. > > Good remark! I understand the point/issue if IPv6 provider is not the > same as IPv4 one. By that way the node may not have the same global > vision of the Domain Name System! I'm having a difficulty seeing the point. A similar situation happens if the user has manually configured a few nameservers in /etc/resolv.conf and then runs either DHCPv4 / DHCPv6. Is it IETF's business to specify whether or not (and if so, how) the entries should be overwritten, prepended/appended, etc. ? Is this done now with DHCPv4? I'm not so sure, but something like "DNS servers configured through this option should take precedence if some existed beforehand" would be acceptable to me Note *no* RFC2119 upper-case keywords. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 02:11:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LAB67f006225; Fri, 21 Feb 2003 02:11:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LAB651006224; Fri, 21 Feb 2003 02:11:06 -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.8+Sun/8.12.8) with ESMTP id h1LAB27f006217 for ; Fri, 21 Feb 2003 02:11:02 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LAB1P17562; Fri, 21 Feb 2003 11:11:03 +0100 (MET) Date: Fri, 21 Feb 2003 11:07:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Pekka Savola Cc: Erik Nordmark , 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 > On the other hand, I'm very worried about specifying a host-router > protocol, as it is a new protocol -- contrary to working operational > practise -- and has a number of difficult issue to tackle with, most > important of them perhaps the security/authorization and interaction > with the routing protocols. I thought you just agree with me that the security/auth issue is independent of the protocol used. > I fail to see an issue with multi-interfaced hosts: all implementations I > know have an explicit toggle to disable/enable packet forwarding between > interfaces ("routing"). I wasn't concerned about that but accidentually getting the host to pass routes in the routing protocol between its interfaces. > > > - the high number of packets exchanged before commencing with real TCP > > > traffic > > > > And the alternative is? > > Possibly some TCP modification. I'm not sure if there are others. What about UDP, SCTP, DDP? Minimizing transport awareness of anycast seems like a reasonable approach to me. 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 Fri Feb 21 02:14:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LAEV7f006372; Fri, 21 Feb 2003 02:14:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LAEV3Y006371; Fri, 21 Feb 2003 02:14:31 -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.8+Sun/8.12.8) with ESMTP id h1LAER7f006364 for ; Fri, 21 Feb 2003 02:14:27 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LAEOP18404; Fri, 21 Feb 2003 11:14:24 +0100 (MET) Date: Fri, 21 Feb 2003 11:10:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Alain Durand , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <963621801C6D3E4A9CF454A1972AE8F54C27@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 > Proposed text: > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 Global Unicast address space to > 2000::/3 for now, IANA might later delegate currently unassigned parts > of the IPv6 address space to the purpose of Global Unicast as well. > Implementations MUST NOT make address range checks for Global Unicast > addresses. I'm missing the association with this document. If we need to have a document which restates the instructions to the IANA to allocate IPv6 addresses, can't we make that a separate exercise? I'm not sure we need one, since IANA seems have enough information at the moment. 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 Fri Feb 21 04:18:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LCIu7f007516; Fri, 21 Feb 2003 04:18:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LCIug9007515; Fri, 21 Feb 2003 04:18:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LCIq7f007508 for ; Fri, 21 Feb 2003 04:18:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LCJ1VK027231 for ; Fri, 21 Feb 2003 04:19:01 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12611 for ; Fri, 21 Feb 2003 05:18:55 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:18:54 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:18:54 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:18:54 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:18:53 Z Received: from localhost (unknown [3ffe:501:100f:1048:39e3:8874:aae1:94ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7D6C715210; Fri, 21 Feb 2003 21:18:51 +0900 (JST) Date: Fri, 21 Feb 2003 21:19:00 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 20 Feb 2003 13:56:59 -0500, >>>>> Ralph Droms said: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. Just as a note: I believe I presented a positive recommendation for advancement. (But it would better to revise the document once to address issues raised during the last call period.) 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 Fri Feb 21 04:56:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LCuT7f007838; Fri, 21 Feb 2003 04:56:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LCuSfu007837; Fri, 21 Feb 2003 04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LCuP7f007830 for ; Fri, 21 Feb 2003 04:56:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LCuZVK003057 for ; Fri, 21 Feb 2003 04:56:35 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11295 for ; Fri, 21 Feb 2003 04:56:29 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:56:28 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:56:27 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:56:27 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 12:56:27 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1LCuKNh003586; Fri, 21 Feb 2003 07:56:21 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA13252; Fri, 21 Feb 2003 07:56:20 -0500 (EST) Message-Id: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 07:56:20 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding unpredictable, difficult to debug behavior (see end of quoted text)... Shouldn't the host receive the same answer to a DNS query, regardless of the resolver to which the query is sent? If so, the order in which resolvers are used by the host shouldn't matter. What is done today in the deployed IPv6 world in a host that has both an IPv6 stack and an IPv4 stack, and a manually configured list of DNS resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Is that configuration actually used? Does the host have two lists: one for IPv6 and one for IPv4? Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in its list of DNS resolvers? I'm hoping we can get some real-world deployment experience injected into the conversation... - Ralph At 10:39 PM 2/20/2003 -0800, Alain Durand wrote: >On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > >>On Thu, 20 Feb 2003, Alain Durand wrote: >>>On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>>>If it's unclear, then we should edit the document to explicitly >>>>identify the addresses as IPv6 addresses. >>>> >>>>This option is intended to return IPv6 configuration information. >>>>IPv4 addresses for DNS resolvers should be provided through DHCPv4... >> >>I symphatize with this -- there are some uses to have DHCPv6 return IPv4 >>addresses too -- but the result would just make the dnsconfig option more >>complex for little benefit. Let's face it: if you deploy DHCPv6, you >>really should have long since deployed IPv6-enabled nameservers too. >> >>So, I think clarifying the scope to do only IPv6 seems like the best >>option by far. > > >Some may scream at this idea, but couldn't we pass an IPv4-mapped address >in there? The DHCPv6 client could recognize this special format >to mean this is actually a v4 address? > > >> >>>Now, let's say that this is the case for DHCP, what should a node that >>>act both as a DHCPv4 and DHCPv6 client do when it will be returned two >>>lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >>>DHCPv6. Which one should take priority? >> >>Implementation decision, but I guess typically the results of the >>latest query take precedence. I don't see a problem here, myself. > >Unpredictable behavior. Difficult to debug. > > - Alain. > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 05:21:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDLV7f008158; Fri, 21 Feb 2003 05:21:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LDLVkU008157; Fri, 21 Feb 2003 05:21:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDLS7f008150 for ; Fri, 21 Feb 2003 05:21:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LDLbVK007454 for ; Fri, 21 Feb 2003 05:21:37 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04079 for ; Fri, 21 Feb 2003 06:21:30 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:21:30 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:19:59 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:21:29 Z Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:21:29 Z Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Fri, 21 Feb 2003 14:21:06 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Feb 2003 14:20:47 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 14:20:45 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLZi8vN/f23m7QVS5ycrelM9us50wAGvQmw From: "BELOEIL Luc FTRD/DMI/CAE" To: "Pekka Savola" Cc: "Alain Durand" , "Ralph Droms" , , , X-OriginalArrivalTime: 21 Feb 2003 13:20:47.0203 (UTC) FILETIME=[0B99DB30:01C2D9AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1LDLS7f008151 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > De : Pekka Savola [mailto:pekkas@netcore.fi] > > > On Fri, 21 Feb 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > Implementation decision, but I guess typically the > results of the > > > > latest query take precedence. I don't see a problem > here, myself. > > > > > > Unpredictable behavior. Difficult to debug. > > > > > > - Alain. > > > > Good remark! I understand the point/issue if IPv6 provider > is not the > > same as IPv4 one. By that way the node may not have the same global > > vision of the Domain Name System! > > I'm having a difficulty seeing the point. A similar > situation happens if > the user has manually configured a few nameservers in > /etc/resolv.conf and > then runs either DHCPv4 / DHCPv6. > Yes > Is it IETF's business to specify whether or not (and if so, how) the > entries should be overwritten, prepended/appended, etc. ? I'm really not sure. > Is this done > now with DHCPv4? > No idea. > I'm not so sure, but something like "DNS servers configured > through this > option should take precedence if some existed beforehand" would be > acceptable to me Note *no* RFC2119 upper-case keywords. > IMO, the "split vision of DNS" remark is useful for service architectures but may not be taken into account in some protocol specifications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 05:28:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDSE7f008375; Fri, 21 Feb 2003 05:28:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LDSEax008374; Fri, 21 Feb 2003 05:28:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDSA7f008367 for ; Fri, 21 Feb 2003 05:28:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LDSJVK008550 for ; Fri, 21 Feb 2003 05:28:19 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26345 for ; Fri, 21 Feb 2003 05:28:14 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:28:13 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:28:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:28:12 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:28:12 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D6A578DB4; Fri, 21 Feb 2003 08:28:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 08:28:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Date: Fri, 21 Feb 2003 08:28:11 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B034C0918@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcLXfeZq2vv01PnpTT2s+GqXLWHE4gCLsdNA From: "Bound, Jim" To: "Fred L. Templin" , "Thomas Narten" Cc: , X-OriginalArrivalTime: 21 Feb 2003 13:28:11.0789 (UTC) FILETIME=[14984BD0:01C2D9AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1LDSA7f008368 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > I'm still of the opinion that some ambiguity exists. Namely, > if a prefix option has the Autonomous flag ("A" bit) set and > the on-link flag ("L" bit) NOT set, one could infer from > reading RFC 2462, section 5.5 that it is OK to go ahead and > configure an address from the (off-link) prefix as specified > in 5.5.3 d). But then, which link would one derive an > interface identifier from in order to form an address? (And, > which interface would one assign the address to?) My read of this scenario as implementor is that I am to use offlink to speak to my default router as one example but I cannot assume those prefixes are on my link. I believe within 2461 this is actually derived but I have not scanned it but pretty sure. Too much work for this moment. > > I believe this should be clarified somewere, e.g., in the > IPv6 node reqt's document. The challenge is in specifying > something that is neither too precise that it precludes > legitimate functionality nor too broad that it opens the door > to security holes and/or misconfigurations. In particular, if > it's not OK for a node to configure an address from an > advertised prefix with the "L" bit not set we should probably > say so somewhere and give some rationale. This is stated. I will go look but it will be days before I come back. But Thomas knows this spec probably from memory banks :--) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 05:28:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDSq7f008404; Fri, 21 Feb 2003 05:28:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LDSphv008403; Fri, 21 Feb 2003 05:28:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDSl7f008393 for ; Fri, 21 Feb 2003 05:28:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LDSuVK008629 for ; Fri, 21 Feb 2003 05:28:56 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01914 for ; Fri, 21 Feb 2003 06:28:51 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:28:50 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Fri, 21 Feb 2003 13:28:50 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Fri, 21 Feb 2003 13:28:50 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay1.sun.com with ESMTP; Fri, 21 Feb 2003 13:28:49 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1LDSRtY014148; Fri, 21 Feb 2003 14:28:27 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1LDSDcP084682; Fri, 21 Feb 2003 14:28:15 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46674 from ; Fri, 21 Feb 2003 14:28:08 +0100 Message-Id: <3E562935.1785DDA8@hursley.ibm.com> Date: Fri, 21 Feb 2003 14:27:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: Michel Py , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on"IPv6 Global Unicast Address Format for the 2000::/3 Prefix" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is good. It leaves some more tricky options open for later if we turn out to need tham. Brian Alain Durand wrote: > > On Friday, February 21, 2003, at 12:47 AM, Michel Py wrote: > > > Alain, > > Your point is valid though, what about this: > > > > Proposed text: > > RFC2374 was the definition of addresses for Format Prefix 001 > > (2000::/3) > > which is formally made historic by this document. Although as specified > > in [ARCH] IANA should limit the IPv6 Global Unicast address space to > > 2000::/3 for now, IANA might later delegate currently unassigned parts > > of the IPv6 address space to the purpose of Global Unicast as well. > > Implementations MUST NOT make address range checks for Global Unicast > > addresses. > > Fine by me. > > - 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 Fri Feb 21 05:56:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDuh7f009220; Fri, 21 Feb 2003 05:56:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LDuhkF009219; Fri, 21 Feb 2003 05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LDud7f009212 for ; Fri, 21 Feb 2003 05:56:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LDunVL004958 for ; Fri, 21 Feb 2003 05:56:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10665 for ; Fri, 21 Feb 2003 05:56:43 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:56:43 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:56:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:56:42 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:56:38 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LDuSd14961; Fri, 21 Feb 2003 20:56:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LDuCo24076; Fri, 21 Feb 2003 20:56:12 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> References: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 20:56:12 +0700 Message-Id: <24074.1045835772@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Feb 2003 07:56:20 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> | Shouldn't the host receive the same answer to a DNS query, regardless of | the resolver to which the query is sent? If so, the order in which | resolvers are used by the host shouldn't matter. It shouldn't matter to the answer (but those who insist on shoving 2faced DNS implementations down everyone's throats can cause problems). It can matter to the workability - often the first resolver listed is the one that should be used, the others are there for backup purposes only, and won't necessarily respond as quickly (they may have smaller cache capacity, slower net links, slower CPU, ...). All this is fine as a backup when the primary resolver happens to be broken, but you wouldn't want to be using it just because you happened to pick the wrong address from a list. | What is done today in the deployed IPv6 world in a host that has both an | IPv6 stack and an IPv4 stack, and a manually configured list of DNS | resolvers? Just about everyone uses IPv4 alone for their resolvers. | Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Allowed, yes, of course, nothing disallows it. | Is that configuration actually used? Probably not at the minute. | Does the host have two lists: one for IPv6 and one for IPv4? This would make no sense. The host (or application in most cases) has one resolver (stub). When called, all that exists is a domain name, there's no particular v4 or v6 preference. The resolver stub needs to contact its back end resolver to resolve the address, whether v4 or v6 is used for this will depend entirely upon what addresses have been configured for the back end resolver (cache). It certainly isn't influenced by the nature of the query, or by what use is intended for the results of the query. | Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in | its list of DNS resolvers? The v4 address would be useless, just like any other (patently) bogus address that is configured. Ignoring that one would be easy. | I'm hoping we can get some real-world deployment experience injected into | the conversation... Since just about no-one is using v6 in their stub resolvers (just a few who will no doubt now speak up...) this might be difficult. On the issue - I think having just v6 addresses in the DHCPv6 option is fine. How the host actually mixes addresses it gets from DHCPv6 and DHCPv4, and other mechanisms is an interesting problem to which we don't yet have any real answers. This is an area where we probably should just say nothing, and wait to see how implementations actually react. But rather than mixing v6 & v4 addresses in one response (as you imply, v6 addresses are no use to a node with only v4, and v4 addresses no use to a node with only v6) it might be better to explicitly add a "priority of this DNS cache" field along with each address. This allows the implicit "this one is better than that one" based upon ordering to be done away with. What's more, if we were to pick a middling well known priority that would implicitly be applied to addresses in a v4 response it also allows v6 to be placed before, or after, v4 addresses in nodes that support both (or even some before, and some after). It doesn't allow v4 addresses to be ranked other than by their implicit ordering, nor for v6 addresses to be inserted in the middle of the v4 list, but we can't have everything (and I doubt anyone wants to go changing the v4 DNS cache list option now). 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 21 07:20:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LFK07f009804; Fri, 21 Feb 2003 07:20:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LFJxvd009803; Fri, 21 Feb 2003 07:19:59 -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.8+Sun/8.12.8) with ESMTP id h1LFJt7f009796 for ; Fri, 21 Feb 2003 07:19:56 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LFK1P18692; Fri, 21 Feb 2003 16:20:01 +0100 (MET) Date: Fri, 21 Feb 2003 16:16:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Mika Liljeberg Cc: Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1043780822.18672.66.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not necessarily. The binding could be stored in the > binding cache as in MIPv6 and TCP could continue using the anycast > address. Depends what happens when the binding times out and needs to be refreshed/re-established. MIPv6 assumes that it can just redo the RR exchange and still end up sending to the same host. That isn't the case for anycast since the anycast address identifies more of a service than a host. Thus to make it more likely that the transport connection survive routing changes it makes sense to get the transport connection basically be redirected to use a unicast member of the anycast group. 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 Fri Feb 21 07:49:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LFnw7f009966; Fri, 21 Feb 2003 07:49:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LFnw2v009965; Fri, 21 Feb 2003 07:49:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LFnt7f009958 for ; Fri, 21 Feb 2003 07:49:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LFo4VL026853 for ; Fri, 21 Feb 2003 07:50:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10870 for ; Fri, 21 Feb 2003 08:49:56 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 15:49:55 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 15:49:54 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 15:49:54 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 15:49:54 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA17644 for ; Fri, 21 Feb 2003 07:48:38 -0800 (PST) Message-Id: <5.1.0.14.2.20030221102512.03416e18@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Feb 2003 10:43:12 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" In-Reply-To: <4.3.2.7.2.20030116113012.033b1ef8@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 Hi All, During the last call period for "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block", there was only one comment (attached). The comment did not raise any specific technical issues with the document, but it did question its usefulness. As I am sure many of you know, documents should only be forwarded to the IESG for approval when there is a consensus of the WG that the document is both technically sound and useful. One ambivalent comment is not sufficient input to demonstrate WG consensus for publishing this document. So, if there are people in the WG who do believe that this document is both technically sound and useful and should be sent to the IESG for publication as an Informational RFC, could you please speak up? You can find the latest version of the document at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt Thanks, Margaret >To: Bob Hinden & Margaret Wasserman >cc: ipng@sunroof.eng.sun.com >Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the > Assignment of Bytes of an IPv6 Address Block" > > >On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote: > > This is a IPv6 working group last call for comments on advancing the > > following document as an Informational RFC: > > > > Title : A Flexible Method for Managing the Assignment of > > Bits of an IPv6 Address Block > > Author(s) : M. Blanchet > > Filename : draft-ietf-ipv6-ipaddressassign-06.txt > > Pages : 8 > > Date : 2003-1-6 > > >I don't have problems with this, though I'm not sure how useful this is >for most (but for some, certainly). > > >A point I've raised in the past is, most operators are not really >interested in optimizing the address assignments on a bit level (provided >that the number of customers is not so high it would be required). >Rather, here we do so with nibbles. Those are easier to calculate in the >head and work better with reverse DNS delegations too. > > >But I'm not sure whether this kind of "coarser approach for flexible >assignment" calls for some text or not. A mention at most, I think. >What do others feel? > > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 08:16:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LGGQ7f010621; Fri, 21 Feb 2003 08:16:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LGGQVc010619; Fri, 21 Feb 2003 08:16:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LGGM7f010612 for ; Fri, 21 Feb 2003 08:16:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LGGVVK017779 for ; Fri, 21 Feb 2003 08:16:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15457 for ; Fri, 21 Feb 2003 09:16:26 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 16:16:21 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 16:16:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 16:16:12 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 16:16:10 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1LGG6Zk010818; Fri, 21 Feb 2003 17:16:07 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1LGG3sb243280; Fri, 21 Feb 2003 17:16:04 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40306 from ; Fri, 21 Feb 2003 17:16:01 +0100 Message-Id: <3E56508D.761B80F6@hursley.ibm.com> Date: Fri, 21 Feb 2003 17:15:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing theAssignment of Bytes of an IPv6 Address Block" References: <5.1.0.14.2.20030221102512.03416e18@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I believe that what matters is whether the RIRs are happy with this. With a positive ack from them, I think publishing this would be useful. If the RIRs have any trouble with it, we would need to think again. Brian Margaret Wasserman wrote: > > Hi All, > > During the last call period for "A Flexible Method for > Managing the Assignment of Bytes of an IPv6 Address > Block", there was only one comment (attached). The > comment did not raise any specific technical issues with > the document, but it did question its usefulness. > > As I am sure many of you know, documents should only be > forwarded to the IESG for approval when there is a consensus > of the WG that the document is both technically sound and > useful. One ambivalent comment is not sufficient input to > demonstrate WG consensus for publishing this document. > > So, if there are people in the WG who do believe that this > document is both technically sound and useful and should be > sent to the IESG for publication as an Informational RFC, > could you please speak up? > > You can find the latest version of the document at: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt > > Thanks, > Margaret > > >To: Bob Hinden & Margaret Wasserman > >cc: ipng@sunroof.eng.sun.com > >Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the > > Assignment of Bytes of an IPv6 Address Block" > > > > > >On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote: > > > This is a IPv6 working group last call for comments on advancing the > > > following document as an Informational RFC: > > > > > > Title : A Flexible Method for Managing the Assignment of > > > Bits of an IPv6 Address Block > > > Author(s) : M. Blanchet > > > Filename : draft-ietf-ipv6-ipaddressassign-06.txt > > > Pages : 8 > > > Date : 2003-1-6 > > > > > >I don't have problems with this, though I'm not sure how useful this is > >for most (but for some, certainly). > > > > > >A point I've raised in the past is, most operators are not really > >interested in optimizing the address assignments on a bit level (provided > >that the number of customers is not so high it would be required). > >Rather, here we do so with nibbles. Those are easier to calculate in the > >head and work better with reverse DNS delegations too. > > > > > >But I'm not sure whether this kind of "coarser approach for flexible > >assignment" calls for some text or not. A mention at most, I think. > >What do others feel? > > > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 21 09:40:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHeb7f011597; Fri, 21 Feb 2003 09:40:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LHebvp011596; Fri, 21 Feb 2003 09:40:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHeX7f011589 for ; Fri, 21 Feb 2003 09:40:33 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LHegVK013348 for ; Fri, 21 Feb 2003 09:40:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29349 for ; Fri, 21 Feb 2003 09:40:37 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:40:35 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:40:35 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:40:35 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:40:34 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LHejaj022261; Fri, 21 Feb 2003 19:40:46 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LHeeo2022260; Fri, 21 Feb 2003 19:40:40 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: a few comments on anycast mechanisms From: Mika Liljeberg To: Erik Nordmark Cc: Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045849238.22159.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 19:40:39 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2003-02-21 at 17:16, Erik Nordmark wrote: > > Not necessarily. The binding could be stored in the > > binding cache as in MIPv6 and TCP could continue using the anycast > > address. > > Depends what happens when the binding times out and > needs to be refreshed/re-established. > MIPv6 assumes that it can just redo the RR exchange and > still end up sending to the same host. That isn't the case for > anycast since the anycast address identifies more of a service than a host. > Thus to make it more likely that the transport connection survive > routing changes it makes sense to get the transport connection basically > be redirected to use a unicast member of the anycast group. I don't know that the binding needs to have a limited lifetime in this case. It can be deleted when the TCP connection is closed (or via a reference counting mechanism in case multiple connections can map to the same binding). MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 09:47:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHlm7f012180; Fri, 21 Feb 2003 09:47:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LHlmnu012179; Fri, 21 Feb 2003 09:47:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHli7f012172 for ; Fri, 21 Feb 2003 09:47:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LHlrVL000459 for ; Fri, 21 Feb 2003 09:47:53 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25321 for ; Fri, 21 Feb 2003 10:47:47 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:47:44 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:47:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:47:42 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:47:41 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2D14A8E0B; Fri, 21 Feb 2003 12:47:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:47:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Date: Fri, 21 Feb 2003 12:47:39 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03240F3E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Thread-Index: AcLY0H8B1jpsDoObQmyT6Em+LRkvSQA/zWZQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Pekka Savola" Cc: "Alan E. Beard" , "Tim Chown" , , X-OriginalArrivalTime: 21 Feb 2003 17:47:39.0861 (UTC) FILETIME=[53E39050:01C2D9D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1LHlj7f012173 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I am on multi6 and just listen and send clarification questions to various participants. But a short comment here. > Has the end-to-end principle failed to teach us anything? > Reliability begins and ends in the end hosts. If each host is > connected over two service providers there are four possible > paths the hosts can switch between on a per-packet basis. > Then the only problem becomes detecting failure. The end > hosts are in an excellent position to do this without having > to generate keepalive messages; a well designed protocol > could switch to an alternate path within a few round trip > times when a path failure occurs. I agree with the above view and much of the problem can be solved by intelligent code and configuration being done by the end system for new IPv6 development and some existing network application infrastructure that is a direct port from IPv4 that has been ported and deployed. SCTP is a clear winner for us here over TCP and it's a new API so we could go there. But more importantly the transition to this requires code on the end systems from suppliers, and then either apps change or shims are built on the end systems. Doing it with TCP is possible till SCTP is more dominant. This is solving the problem at layer 7 and 4. And that means we need new platform code releases and development to make it happen. Which is fine but will take time. Layer 1 and 3 may be able to do something too but that will take time and require new code and platform releases. I think we need to first pick which way we want to specify this or both and provide technical spec on what each mean. It is really transparent to IPv6 but IPv6 has a better chance of getting this right. > Multi6 has been gravitating towards multi-address multihoming > solutions for a while now, but unfortunately it seems > impossible to move foward. Hmmm. At some point this needs to get done folks. Not sure what will cause it, but I believe it may be external forces resolve it for us. P.S. Mutli6 should not MUST SCTP as Diameter tried (well was forced) that and all the Diameter products shipping are doing it with TCP and same for some other things like RDMA. But Multi6 could do the community a big favor by stressing that SCTP really helps this problem within its inherent failover capabilities via the network association for the connections. Regards, /jim > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 09:49:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHne7f012343; Fri, 21 Feb 2003 09:49:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LHnd0i012342; Fri, 21 Feb 2003 09:49:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LHnX7f012314 for ; Fri, 21 Feb 2003 09:49:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LHngVL001199 for ; Fri, 21 Feb 2003 09:49:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29480 for ; Fri, 21 Feb 2003 10:49:36 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:49:22 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:49:21 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:49:21 Z Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 17:49:20 Z Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LHk3N26412; Fri, 21 Feb 2003 11:46:03 -0600 (CST) Date: Fri, 21 Feb 2003 10:48:44 -0700 Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Robert Elz From: Ted Lemon In-Reply-To: <24074.1045835772@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure why you would have a deployed DHCPv6 server and not deploy a DNS resolver that listens to requests on an IPv6 socket. Can anybody give a rationale for this? Has anybody done this? Was it a problem? In principle, there is nothing that would prevent you from configuring your DHCPv6 server to return an encapsulated IPv4 address, but as various people have said, this might produce a not-useful result. I think that the idea of having a DNS resolver priority list is a reasonable answer to the problem of "what do we do if we have both IPv4 and IPv6 addresses for resolvers," but I also think that it's a complicated answer, and I do not believe that the problem it solves is a compelling one. It adds significant special-case code to the DHCP client, and I don't think it produces a useful benefit. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 10:33:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LIX17f013203; Fri, 21 Feb 2003 10:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LIX1oQ013202; Fri, 21 Feb 2003 10:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LIWw7f013195 for ; Fri, 21 Feb 2003 10:32:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LIX7VK001749 for ; Fri, 21 Feb 2003 10:33:07 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04229 for ; Fri, 21 Feb 2003 10:33:01 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 18:32:24 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 18:31:50 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 18:31:49 Z Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 18:31:49 Z Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1LIVTBP081744; Fri, 21 Feb 2003 13:31:29 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1LISurs032572; Fri, 21 Feb 2003 11:28:57 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h1LIP297013632; Fri, 21 Feb 2003 13:25:02 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h1LIP18R013627; Fri, 21 Feb 2003 13:25:01 -0500 Message-Id: <200302211825.h1LIP18R013627@rotala.raleigh.ibm.com> To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: Message from ftemplin@iprg.nokia.com of "Tue, 18 Feb 2003 10:44:53 PST." <3E527F25.5020106@iprg.nokia.com> Date: Fri, 21 Feb 2003 13:25:01 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Fred L. Templin" writes: > I'm still of the opinion that some ambiguity exists. Namely, if a prefix > option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit) > NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK > to go ahead and configure an address from the (off-link) prefix as specified > in 5.5.3 d). Good, as that is the intended behavior. > But then, which link would one derive an interface identifier > from in order to form an address? (And, which interface would one assign > the address to?) This question applies to any address a node autoconfigures, regardless of the setting of the L-bit. The scope of the advertisement of course applies to the interface on which it receives. It's not that surprising to me that the wording on the L-bit still seems odd. My recollection is that the exact wording you have been quoting was put in explicitely because the previous wording was even more confusing. :-) The whole point is that if the A bit is set, you do the processing associated with generating an address. To do this, you don't need to know whether the prefix is considered on-link or not. Likewise, the list of prefixes to consider on-link is independent of any addresses you may (or may not) have configured. They are two logically orthogonal issues. I still do not (yet) see the need for further clarifications in the documents (and certainly not in node requirements, for the level of detail we're talking about here). 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 Fri Feb 21 11:14:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LJEk7f014004; Fri, 21 Feb 2003 11:14:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LJEkm7014003; Fri, 21 Feb 2003 11:14:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LJEh7f013996 for ; Fri, 21 Feb 2003 11:14:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LJEqVL001387 for ; Fri, 21 Feb 2003 11:14:52 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23917 for ; Fri, 21 Feb 2003 12:14:46 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 19:14:46 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 19:14:45 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 19:14:45 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 19:14:45 Z 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 LAA24239; Fri, 21 Feb 2003 11:14:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1LJEbL23908; Fri, 21 Feb 2003 11:14:37 -0800 X-mProtect: <200302211914> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4vzyPc; Fri, 21 Feb 2003 11:14:36 PST Message-Id: <4.3.2.7.2.20030221111336.030cb320@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 11:14:29 -0800 To: Thomas Narten From: Bob Hinden Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200302211825.h1LIP18R013627@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I still do not (yet) see the need for further clarifications in the >documents (and certainly not in node requirements, for the level of >detail we're talking about here). My view as well. 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 Fri Feb 21 12:15:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LKFn7f014717; Fri, 21 Feb 2003 12:15:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1LKFnGk014716; Fri, 21 Feb 2003 12:15:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1LKFi7f014709 for ; Fri, 21 Feb 2003 12:15:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1LKFqVL022297 for ; Fri, 21 Feb 2003 12:15:52 -0800 (PST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18616 for ; Fri, 21 Feb 2003 13:15:42 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAO00GU9DK9H9@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:14:34 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAO00K1ADK8UH@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 21 Feb 2003 13:14:33 -0700 (MST) Date: Fri, 21 Feb 2003 12:15:41 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3FCBEDD2-45D9-11D7-9278-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, February 21, 2003, at 04:56 AM, Ralph Droms wrote: > Regarding unpredictable, difficult to debug behavior (see end of > quoted text)... > > Shouldn't the host receive the same answer to a DNS query, regardless > of the resolver to which the query is sent? If so, the order in which > resolvers are used by the host shouldn't matter. There might be performance/security issues. > > What is done today in the deployed IPv6 world in a host that has both > an IPv6 stack and an IPv4 stack, and a manually configured list of DNS > resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for > resolvers? Yes, in /etc/resolv.conf > Is that configuration actually used? Yes > Does the host have two lists: one for IPv6 and one for IPv4? No, one list which include either v4 or v6 addreses > > Suppose the host only has an IPv6 stack but both IPv6 and IPv4 > addresses in its list of DNS resolvers? then obviously it should ignore the v4 one, the same way a v4-only host should ignore AAAA records. > I'm hoping we can get some real-world deployment experience injected > into the conversation... > > - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 16:00:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M00p7f017301; Fri, 21 Feb 2003 16:00:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1M00pIc017300; Fri, 21 Feb 2003 16:00:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M00l7f017293 for ; Fri, 21 Feb 2003 16:00:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1M00uVK026540 for ; Fri, 21 Feb 2003 16:00:57 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23251 for ; Fri, 21 Feb 2003 16:00:51 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 00:00:50 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 00:00:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 00:00:49 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 00:00:48 Z Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sat, 22 Feb 2003 01:02:30 +0100 Message-Id: <02e901c2da05$b01bd1a0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5.1.0.14.2.20030221102512.03416e18@mail.windriver.com> Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" Date: Sat, 22 Feb 2003 01:02:27 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm ok with the document to be sent to the IESG. Regards, Jordi ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Friday, February 21, 2003 4:43 PM Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" > > Hi All, > > During the last call period for "A Flexible Method for > Managing the Assignment of Bytes of an IPv6 Address > Block", there was only one comment (attached). The > comment did not raise any specific technical issues with > the document, but it did question its usefulness. > > As I am sure many of you know, documents should only be > forwarded to the IESG for approval when there is a consensus > of the WG that the document is both technically sound and > useful. One ambivalent comment is not sufficient input to > demonstrate WG consensus for publishing this document. > > So, if there are people in the WG who do believe that this > document is both technically sound and useful and should be > sent to the IESG for publication as an Informational RFC, > could you please speak up? > > You can find the latest version of the document at: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt > > Thanks, > Margaret > > > > >To: Bob Hinden & Margaret Wasserman > >cc: ipng@sunroof.eng.sun.com > >Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the > > Assignment of Bytes of an IPv6 Address Block" > > > > > >On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote: > > > This is a IPv6 working group last call for comments on advancing the > > > following document as an Informational RFC: > > > > > > Title : A Flexible Method for Managing the Assignment of > > > Bits of an IPv6 Address Block > > > Author(s) : M. Blanchet > > > Filename : draft-ietf-ipv6-ipaddressassign-06.txt > > > Pages : 8 > > > Date : 2003-1-6 > > > > > >I don't have problems with this, though I'm not sure how useful this is > >for most (but for some, certainly). > > > > > >A point I've raised in the past is, most operators are not really > >interested in optimizing the address assignments on a bit level (provided > >that the number of customers is not so high it would be required). > >Rather, here we do so with nibbles. Those are easier to calculate in the > >head and work better with reverse DNS delegations too. > > > > > >But I'm not sure whether this kind of "coarser approach for flexible > >assignment" calls for some text or not. A mention at most, I think. > >What do others feel? > > > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 21:35:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5Za7f018058; Fri, 21 Feb 2003 21:35:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1M5ZaKx018057; Fri, 21 Feb 2003 21:35:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5ZW7f018050 for ; Fri, 21 Feb 2003 21:35:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1M5ZfVL011874 for ; Fri, 21 Feb 2003 21:35:41 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21205 for ; Fri, 21 Feb 2003 22:35:35 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:35:34 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:34:02 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:35:34 Z Received: from dhcp-168-17-124.autonomica.se ([194.230.196.125] [194.230.196.125]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:35:27 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5Yjif008512; Sat, 22 Feb 2003 06:34:57 +0100 (CET) Date: Fri, 21 Feb 2003 16:19:36 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Alan E. Beard" , Tim Chown , , , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'll take one particular issue, and Cc: to multi6 as I believe it is a > very important thing to consider. > > On Fri, 14 Feb 2003, Alan E. Beard wrote: >>>> Most of the end-user-network managers among my clients now >>>> multihome, >>>> and >>>> will continue to require multihomed service in future. In every >>>> case >>>> where the user's network is multihomed, the multiple independent >>>> connections are seen as crucial for maintenance of high >>>> availability of >>> >>> [Kurtis:] >>> I find this funny. A number of studies have shown that if this is >>> what >>> you are after, multihoming and BGP is the wrong way to go - but never >>> mind. >>> >> Your comment may be true, but my clients are nonetheless unwilling to >> risk >> the possibility of an extended network outage on a single ISP (while >> not >> frequent, these events are far from unprecedented) rendering their >> online >> customer-support environment unavailable for several hours, much less >> for >> a day. Shorter outages (on the order of minutes in the single >> digits) are >> tolerated, provided that such outages are infrequent. > > This is a very problematic approach IMO. > > Need more resiliency? Network outages unacceptable? > > The right place to fix this is the network service provider, period. > Nothing else seems like a scalable approach. > > Consider a case when many companies _phone_ services would have been > changed to VoIP. IP would be a critical service. Do the enterprises > protect against failures by getting more ISP's? Unscalable. No, the > ISP's _must_ get better. Pick one well when choosing them. > > When ISP's have SLA's, a lot of customers for which continued service > is > of utmost importance, the networks *will* work. There is just no other > choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 > minutes of network outage, things _will_ happen. > > It just seems the mentality in some networks is that network outages > are > ok, networks don't have to be designed with multiple connections, > etc.etc. > > That must change if we want to build a mission-critical IP > infrastructure. > Instead of making every site try to deal with the problems themselves. > > This is my view as ISP and an end-user. > This highlights another issue with the solution to the multi6 problem - convergence time. We need a solution that also improves this, besides scales in the DFZ. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 21:49:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5nL7f018258; Fri, 21 Feb 2003 21:49:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1M5nKMH018257; Fri, 21 Feb 2003 21:49:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5nE7f018244 for ; Fri, 21 Feb 2003 21:49:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1M5nNVL014298 for ; Fri, 21 Feb 2003 21:49:23 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02800 for ; Fri, 21 Feb 2003 21:49:17 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:49:15 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:49:15 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:49:15 Z Received: from dhcp-168-17-124.autonomica.se ([194.230.196.125] [194.230.196.125]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:49:09 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5lqif008671; Sat, 22 Feb 2003 06:48:19 +0100 (CET) Date: Fri, 21 Feb 2003 16:35:15 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, randy@psg.com To: Lars Erik Gullerud From: Kurt Erik Lindqvist In-Reply-To: <1045753567.81330.33.camel@sabre.ncc.catchcom.no> Message-Id: <12EFDD17-45B2-11D7-932B-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In a perfect world I'm sure I'd agree with you. In real life however, > the fact of the matter is that customers want multihoming, and it > doesn't matter to the customers if that is a problematic approach that > doesn't scale for the SPs. Doesn't even matter if it's technically the > best solution for THEM, customers are not known for picking the best > solutions, nor listening to their providers suggestions for better > ones, > half the time. And, the simple fact of the market economy is that what > the customers want, the providers are going to sell. ....which explains a lot of bad stuff being deployed, but that is another WG..:=) > > Making the IP backbones more resilient costs money. You get that money > from your customers. You get the customers by selling them what they > are > asking for. What they are asking for is multihoming. If they can't > multihome with IPv6, well, then they won't use IPv6 until they can. If > the customers don't want to use IPv6, the providers won't spend the > money to support it. Agreed!!! > ...and this is yet another rehash of a discussion that has already been > had so many times by so many people that I'm sure we can just copy & > paste from here on out. > > The fact of the matter is, whether it's the best approach or not, we > need a solution for customers to multihome. So let's bring our > attention > back to that, shall we? > Agreed. I have a suggestion....:) - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 21 21:50:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5oo7f018339; Fri, 21 Feb 2003 21:50:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1M5oo0O018338; Fri, 21 Feb 2003 21:50:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1M5ok7f018328 for ; Fri, 21 Feb 2003 21:50:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1M5otVK014264 for ; Fri, 21 Feb 2003 21:50:55 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28307 for ; Fri, 21 Feb 2003 22:50:49 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:47:59 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:47:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:47:58 Z Received: from dhcp-168-17-124.autonomica.se ([194.230.196.125] [194.230.196.125]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 05:47:52 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5kBif008668; Sat, 22 Feb 2003 06:46:29 +0100 (CET) Date: Fri, 21 Feb 2003 16:29:22 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030220112127.Q61596-100000@sequoia.muada.com> Message-Id: <40BA4A2F-45B1-11D7-932B-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no technical reason why a single service provider network can > do better than a similar network that consists of several smaller > See Abha and Craigs paper on convergence of BGP. Personally I would go for a large provider with multiple connections. Last fall I was invited to a conference in Sweden to debate multihoming and the enterprise. Before me was this enterprise IT manager who showed how much more resilient his network was with two BGP sessions. While he talked I checked his announcements just to find that one of the providers bought transit from the other. You can't buy clue. > service provider networks. Sure, BGP as-is doesn't provide the seamless > failorver some people would like. It annoys me to no end that Cisco > uses > a 180 second default hold time for BGP, twice the already too > conservative value that is is suggested in the RFC. This means that > when > a circuit goes down BGP takes two or three minutes to notice this. I > always recommend configuring a hold time of 15 seconds, but it seems > some vendors have designed their stuff in such a way that sessions can > fail with this value when the box is busy. But IGPs have the same > fundamental problem (although the details may differ). OSPF for > instance > takes 40 seconds to detect a dead circuit. there was a fix proposed in San Diego (although for IS-IS) but that was voted down. There was pros and cons. > We are _very_ far from a situation where even the best ISP provides a > service level that is better then the one you get from multihoming even > if you consider failover delays. I would like to see numbers for this. My experience says otherwise. Perhaps CAIDA have something on this? Or the RIPE RIS boxes could give some insight. > > Also, these approaches aren't mutually exclusive. ISPs should get > better. Multihoming should get better. Yes, but not for the same reasons. > At the same time, we should recognize that it is simply impossible to > have the same failover delays at layer 3 as at layer 1. From my experience you can get very close, but I am very close to a NDA I have signed. > My experience with SLAs is that they are a marketing tool and job > security for bureaucrats. They don't make the worst case any better, > they only make the worst case slightly less frequent. To some extent I agree. There was inflation in SLAs some year ago. This was bad for the entire industry. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 02:48:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MAmW7f020241; Sat, 22 Feb 2003 02:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MAmVBt020240; Sat, 22 Feb 2003 02:48:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MAmS7f020233 for ; Sat, 22 Feb 2003 02:48:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MAmaVK027148 for ; Sat, 22 Feb 2003 02:48:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01664 for ; Sat, 22 Feb 2003 02:48:30 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 10:48:30 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Sat, 22 Feb 2003 10:48:29 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Sat, 22 Feb 2003 10:48:29 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP; Sat, 22 Feb 2003 10:48:28 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MAmXaj027089; Sat, 22 Feb 2003 12:48:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MAmSxt027087; Sat, 22 Feb 2003 12:48:28 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 12:48:27 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2003-02-21 at 08:25, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: > > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > > If it's unclear, then we should edit the document to explicitly > > > identify the addresses as IPv6 addresses. > > > > > > This option is intended to return IPv6 configuration information. > > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return IPv4 > addresses too -- but the result would just make the dnsconfig option more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format if necessary. Just add some text explaining this. With our hybrid IPv4/IPv6 stack implementation this would work out of the box. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 03:09:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MB9v7f020582; Sat, 22 Feb 2003 03:09:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MB9v35020581; Sat, 22 Feb 2003 03:09:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MB9r7f020574 for ; Sat, 22 Feb 2003 03:09:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MBA2VK029812 for ; Sat, 22 Feb 2003 03:10:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10474 for ; Sat, 22 Feb 2003 04:09:57 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:02:57 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Sat, 22 Feb 2003 11:01:23 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Sat, 22 Feb 2003 11:02:56 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP; Sat, 22 Feb 2003 11:02:55 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MB31aj027243; Sat, 22 Feb 2003 13:03:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MB30t3027242; Sat, 22 Feb 2003 13:03:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: BELOEIL Luc FTRD/DMI/CAE Cc: Alain Durand , Pekka Savola , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045911780.27180.5.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:03:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2003-02-21 at 11:07, BELOEIL Luc FTRD/DMI/CAE wrote: > > Some may scream at this idea, but couldn't we pass an IPv4-mapped > > address > > in there? The DHCPv6 client could recognize this special format > > to mean this is actually a v4 address? I think this is a good idea. > I feel ill at ease with such a solution. How your DHCPv6 client, running > a node, is aware that there is an IPv4 stack enable on that same node ? > If it is not, v4-mapped addresses could be harmfull, couldn't they ? Not really. Why would a network administrator advertise IPv4 DNS servers on a network with IPv6 only nodes? Even if there are some IPv6 only nodes on the network, the host resolver on those nodes will simply try to use the IPv4-mapped address and fail, and move on the the next one as it would do with any malfunctioning DNS server. I don't think the DHCP client has to care whether IPv4 is enabled on the node (although it could attempt to check that). All it has to do is configure the DNS addresses and let the host resolver take it from there. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 03:13:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBDq7f020701; Sat, 22 Feb 2003 03:13:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MBDqMA020700; Sat, 22 Feb 2003 03:13:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBDm7f020684 for ; Sat, 22 Feb 2003 03:13:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MBDvVL026316 for ; Sat, 22 Feb 2003 03:13:57 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11842 for ; Sat, 22 Feb 2003 04:13:51 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:13:51 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Sat, 22 Feb 2003 11:13:51 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Sat, 22 Feb 2003 11:13:51 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP; Sat, 22 Feb 2003 11:13:50 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MBDmP29761; Sat, 22 Feb 2003 13:13:48 +0200 Date: Sat, 22 Feb 2003 13:13:48 +0200 (EET) From: Pekka Savola To: Mika Liljeberg cc: Alain Durand , Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045910906.26677.29.camel@devil> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 22 Feb 2003, Mika Liljeberg wrote: > On Fri, 2003-02-21 at 08:25, Pekka Savola wrote: > > On Thu, 20 Feb 2003, Alain Durand wrote: > > > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > > > If it's unclear, then we should edit the document to explicitly > > > > identify the addresses as IPv6 addresses. > > > > > > > > This option is intended to return IPv6 configuration information. > > > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return IPv4 > > addresses too -- but the result would just make the dnsconfig option more > > complex for little benefit. Let's face it: if you deploy DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format > if necessary. Just add some text explaining this. With our hybrid > IPv4/IPv6 stack implementation this would work out of the box. IMO, we should just say "IPv6 addresses" (the critical thing here is the size of the address -- no checks are done to validate them!), and nothing about mapped addresses. If some want to push mapped addresses in there, that's fine by me -- if your DNS resolver supports mapped addresses in /etc/resolv.conf (or equivalent). No special code/text, is my opinion! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 03:18:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBHx7f020969; Sat, 22 Feb 2003 03:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MBHx1r020968; Sat, 22 Feb 2003 03: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBHs7f020946 for ; Sat, 22 Feb 2003 03:17:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MBI3VK001233 for ; Sat, 22 Feb 2003 03:18:03 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25346 for ; Sat, 22 Feb 2003 04:17:58 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:17:42 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Sat, 22 Feb 2003 11:17:41 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Sat, 22 Feb 2003 11:17:41 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay1.sun.com with ESMTP; Sat, 22 Feb 2003 11:17:40 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBHlaj027296; Sat, 22 Feb 2003 13:17:48 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBHiY2027295; Sat, 22 Feb 2003 13:17:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045912663.27180.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:17:44 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-02-22 at 13:13, Pekka Savola wrote: > IMO, we should just say "IPv6 addresses" (the critical thing here is the > size of the address -- no checks are done to validate them!), and nothing > about mapped addresses. > > If some want to push mapped addresses in there, that's fine by me -- if > your DNS resolver supports mapped addresses in /etc/resolv.conf (or > equivalent). > > No special code/text, is my opinion! That's good. I agree. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 03:23:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBN07f021269; Sat, 22 Feb 2003 03:23:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MBN0DQ021268; Sat, 22 Feb 2003 03:23:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MBMv7f021261 for ; Sat, 22 Feb 2003 03:22:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MBN6VK002023 for ; Sat, 22 Feb 2003 03:23:06 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04929 for ; Sat, 22 Feb 2003 03:23:00 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:23:00 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:21:27 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:23:00 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 11:22:59 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBNEaj027331; Sat, 22 Feb 2003 13:23:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBNDPc027330; Sat, 22 Feb 2003 13:23:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045912992.27180.14.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:23:12 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-02-20 at 20:56, Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. I would like to see this specification move forward. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 04:54:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MCsI7f021977; Sat, 22 Feb 2003 04:54:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MCsIAl021976; Sat, 22 Feb 2003 04:54:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MCsF7f021969 for ; Sat, 22 Feb 2003 04:54:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MCsOVK013576 for ; Sat, 22 Feb 2003 04:54:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09581 for ; Sat, 22 Feb 2003 05:54:18 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 12:54:18 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Sat, 22 Feb 2003 12:54:18 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Sat, 22 Feb 2003 12:54:18 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP; Sat, 22 Feb 2003 12:54:17 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h1MCs1I04267; Sat, 22 Feb 2003 04:54:01 -0800 (PST) From: Bill Manning Message-Id: <200302221254.h1MCs1I04267@boreas.isi.edu> Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912663.27180.12.camel@devil> from Mika Liljeberg at "Feb 22, 3 01:17:44 pm" To: mika.liljeberg@welho.com (Mika Liljeberg) Date: Sat, 22 Feb 2003 04:54:00 -0800 (PST) Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk regarding the use of mapped addresses: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt might be a useful ID to review before committing this draft to the stds process. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 05:25:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MDPJ7f022274; Sat, 22 Feb 2003 05:25:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MDPIns022273; Sat, 22 Feb 2003 05:25:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MDPF7f022266 for ; Sat, 22 Feb 2003 05:25:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MDPOVL013401 for ; Sat, 22 Feb 2003 05:25:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29803 for ; Sat, 22 Feb 2003 06:25:19 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 13:25:18 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Sat, 22 Feb 2003 13:25:17 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Sat, 22 Feb 2003 13:25:17 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP; Sat, 22 Feb 2003 13:25:16 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MDPXaj027791; Sat, 22 Feb 2003 15:25:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MDPVQX027788; Sat, 22 Feb 2003 15:25:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: IPv4-mapped API [Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt] From: Mika Liljeberg To: Bill Manning Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <200302221254.h1MCs1I04267@boreas.isi.edu> References: <200302221254.h1MCs1I04267@boreas.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045920330.27180.45.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 15:25:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Topic changed. If you respond to this, please drop unrelated mailing lists.] On Sat, 2003-02-22 at 14:54, Bill Manning wrote: > regarding the use of mapped addresses: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt > > might be a useful ID to review before committing this draft to the > stds process. These issues are completely unrelated. The API issues are real but they are not something that can or should be considered in a protocol specification. [Sorry for the off-topicness of the following] I'm not too happy about RFC2553 myself in this respect, and I strongly support the "Alternative solution" (fully specify IPv4-mapped behaviour) in the above mentioned draft. I can attest from implementation experience that it is possible to create a hybrid IPv4/IPv6 stack implementation that uses around 80-90% shared code between IPv4 and IPv6. All IPv4 addresses are handled in IPv4-mapped format internally inside the stack. Our sockets API is (mostly) version agnostic. Most applications are not even aware which IP version they are using. The OS is not a unix derivative and did not have the legacy baggage of the BSD style sockets API. The API that was already defined for IPv4 yielded very easily to support IPv6. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 05:45:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MDjQ7f022628; Sat, 22 Feb 2003 05:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MDjQIE022627; Sat, 22 Feb 2003 05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MDjM7f022617 for ; Sat, 22 Feb 2003 05:45:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MDjVVL015790 for ; Sat, 22 Feb 2003 05:45:31 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24745 for ; Sat, 22 Feb 2003 06:45:21 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 13:45:21 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Sat, 22 Feb 2003 13:43:47 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Sat, 22 Feb 2003 13:45:20 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay11.sun.com with ESMTP; Sat, 22 Feb 2003 13:45:20 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1MDjEh17701; Sat, 22 Feb 2003 14:45:14 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1MDgNof043959; Sat, 22 Feb 2003 14:42:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302221342.h1MDgNof043959@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mika Liljeberg cc: Bill Manning , pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: IPv4-mapped API [Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt] In-reply-to: Your message of 22 Feb 2003 15:25:31 +0200. <1045920330.27180.45.camel@devil> Date: Sat, 22 Feb 2003 14:42: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: On Sat, 2003-02-22 at 14:54, Bill Manning wrote: > regarding the use of mapped addresses: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt > > might be a useful ID to review before committing this draft to the > stds process. These issues are completely unrelated. The API issues are real but they are not something that can or should be considered in a protocol specification. => note there is no consensus at all about this ID. I'm not too happy about RFC2553 myself in this respect, and I strongly support the "Alternative solution" (fully specify IPv4-mapped behaviour) in the above mentioned draft. => I agree but some of us are relunctant to put the burden of a full IPv4-mapped behavior on the shoulders of (other) implementors. I can attest from implementation experience that it is possible to create a hybrid IPv4/IPv6 stack implementation that uses around 80-90% shared code between IPv4 and IPv6. All IPv4 addresses are handled in IPv4-mapped format internally inside the stack. => IMHO this is the best thing to do where a dual stack is written from scratch. Our sockets API is (mostly) version agnostic. => so you should adopt our local credo: "IPv6 is not a new protocol, it is a new version of the IP protocol." Most applications are not even aware which IP version they are using. The OS is not a unix derivative and did not have the legacy baggage of the BSD style sockets API. The API that was already defined for IPv4 yielded very easily to support IPv6. 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 22 06:19:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MEJQ7f022961; Sat, 22 Feb 2003 06:19:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MEJQnc022960; Sat, 22 Feb 2003 06:19:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MEJN7f022953 for ; Sat, 22 Feb 2003 06:19:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MEJVVL019662 for ; Sat, 22 Feb 2003 06:19:32 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03930 for ; Sat, 22 Feb 2003 07:19:26 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 14:19:25 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Sat, 22 Feb 2003 14:17:52 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Sat, 22 Feb 2003 14:19:25 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP; Sat, 22 Feb 2003 14:19:24 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MEJXaj028005; Sat, 22 Feb 2003 16:19:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MEJPor028002; Sat, 22 Feb 2003 16:19:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: IPv4-mapped API [Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt] From: Mika Liljeberg To: Francis Dupont Cc: Bill Manning , pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: <200302221342.h1MDgNof043959@givry.rennes.enst-bretagne.fr> References: <200302221342.h1MDgNof043959@givry.rennes.enst-bretagne.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1045923563.27185.73.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 16:19:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-02-22 at 15:42, Francis Dupont wrote: > I'm not too happy about RFC2553 myself in this respect, and I strongly > support the "Alternative solution" (fully specify IPv4-mapped behaviour) > in the above mentioned draft. > > => I agree but some of us are relunctant to put the burden of a full > IPv4-mapped behavior on the shoulders of (other) implementors. Point taken. From my point of view it would be very useful to have a specification how IPv4-mapped should behave in the IPv6 API but I'm not about to try and force this on those who have to deal with the BSD sockets API. It would be a pity, though, if BSD like systems were to not support it. Portability problems are bound to ensue. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 07:13:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MFDl7f023359; Sat, 22 Feb 2003 07:13:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MFDlgU023358; Sat, 22 Feb 2003 07:13:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MFDi7f023351 for ; Sat, 22 Feb 2003 07:13:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MFDrVK004383 for ; Sat, 22 Feb 2003 07:13:53 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00731 for ; Sat, 22 Feb 2003 07:13:48 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 15:13:47 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Sat, 22 Feb 2003 15:13:46 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Sat, 22 Feb 2003 15:13:46 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP; Sat, 22 Feb 2003 15:13:46 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MFDie30925; Sat, 22 Feb 2003 17:13:44 +0200 Date: Sat, 22 Feb 2003 17:13:43 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: a few comments on anycast mechanisms 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, 21 Feb 2003, Erik Nordmark wrote: > > On the other hand, I'm very worried about specifying a host-router > > protocol, as it is a new protocol -- contrary to working operational > > practise -- and has a number of difficult issue to tackle with, most > > important of them perhaps the security/authorization and interaction > > with the routing protocols. > > I thought you just agree with me that the security/auth issue is independent > of the protocol used. Well .. it is, in a sense that security/auth must be done _somehow_, _but_ certain protocols (like BGP) already provide this functionality to the sufficient degree. > > I fail to see an issue with multi-interfaced hosts: all implementations I > > know have an explicit toggle to disable/enable packet forwarding between > > interfaces ("routing"). > > I wasn't concerned about that but accidentually getting the host > to pass routes in the routing protocol between its interfaces. You've configured the routing protocol wrong in a few places (host itself, and it's neighboring routers: they must have access lists to prevent everything but the anycast announcement) if this happens. With IGP's it's easier, but I'm not really advocating one due to signicantly more difficult control mechanisms. > > > > - the high number of packets exchanged before commencing with real TCP > > > > traffic > > > > > > And the alternative is? > > > > Possibly some TCP modification. I'm not sure if there are others. > > What about UDP, SCTP, DDP? > Minimizing transport awareness of anycast seems like > a reasonable approach to me. For connection-oriented protocols, similar modifications would have to be done. Note that e.g. in SCTP this might not be a problem -- because there is already a concept of multiple addresses -- anycast could just be one which is never really used. For connection-less protocols, source address should not matter, that much. But certainly, I agree that "protocol independence" has certain value :-). But it also has a price tag attached to it.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 10:16:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MIGc7f024073; Sat, 22 Feb 2003 10:16:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MIGcs9024072; Sat, 22 Feb 2003 10:16:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MIGZ7f024065 for ; Sat, 22 Feb 2003 10:16:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MIGiVK028607 for ; Sat, 22 Feb 2003 10:16:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16680 for ; Sat, 22 Feb 2003 11:16:38 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 18:16:38 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 18:16:37 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 18:16:37 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 18:16:37 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MIGZn31884 for ; Sat, 22 Feb 2003 20:16:35 +0200 Date: Sat, 22 Feb 2003 20:16:34 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: comments: draft-huston-ipv6-documentation-prefix-00.txt Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, A few comments; I didn't bother splitting "editorial" and "substantial", as it isn't so long a document. IPv6 Documentation Address draft-huston-ipv6-documentation-prefix-00.txt ==> synchronize the title: Address Space? Address Prefix? This prefix has been assigned by the Asia Pacific Network Information Centre (APNIC) for this purpose, on behalf of the Regional Internet Registries. and later: Following acceptance within the addressing community of a proposal for a block of IPv6 address space to be created for documentation purposes, the Regional Internet Registries allocated a unicast address prefix for documentation purposes. ==> "on behalf" (and similar in the later quote) implies that RIR's have agreed on this beforehand. I've hard time believing this is an accurate statement, as I've never came across discussion about reserving a doc prefix from IANA allocations in RIPE. Have I missed something? To allow documentation to accurately describe deployment examples the use of site local or link local addresses is inappropriate, and a ==> s/examples/examples,/ prefix-based proposal [3]for multicast addresses. ==> s/[3]/[3] / Multicast addresses can also be reserved for documentation using this document reserved address space together with the Unicast prefix-based proposal [3]for multicast addresses. ==> note that you may also have to be able to demonstrate or document multicast addresses which do *not* use unicast-prefix-based addressing, so reserving a documentation prefix from other parts of the multicast prefixes is probably also at least marginally useful. address block to the list of non-routeable IPv6 address space, and if ==> s/routeable/routable/ 4. IANA Considerations IANA is to reserve 2001:0DB8::/32 address space out of the global unicast address space as a documentation-only prefix, and note this reservation in the IPv6 address registry. No end party is to be assigned this address. ==> will someone make a whois entry for this, explaining what it is? 5. Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [4]. ==> remove the last sentence, it is irrelevant IMO, and gives a false impression that that's all you have to do to secure IPv6 packets. Or if not, at least also refer to ESP or some other IPsec document, too. References ==> split the references to normative and informative; I assume [1] and [3] are normative. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 12:57:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MKvS7f024680; Sat, 22 Feb 2003 12:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MKvS8L024679; Sat, 22 Feb 2003 12:57:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MKvP7f024669 for ; Sat, 22 Feb 2003 12:57:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MKvYVK024694 for ; Sat, 22 Feb 2003 12:57:34 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27075 for ; Sat, 22 Feb 2003 13:57:28 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 20:57:26 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 20:57:26 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 20:57:26 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 20:57:25 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MKvBU32692; Sat, 22 Feb 2003 22:57:11 +0200 Date: Sat, 22 Feb 2003 22:57:10 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Feb 2003, Ralph Droms wrote: > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > options and a mechanism through which a "delegating router" (e.g., an ISP > aggregation device) can assign and delegate one or more prefixes to a > "requesting router" (e.g., CPE). This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt A few comments. Bigger issues -- I'm sorry for bringing them up so late (relatively), but I haven't really thought/read about the big picture, before. 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be mostly redundant -- the requesting router should just take the minimum of lifetimes of the prefixes, calculate it in the same fashion, that's it. Of course, there is an assumption (which doesn't seem to be properly addressed!) that the requesting router is free to refresh the delegation when it feels right, even every hour, day, month etc. without regard to the lifetimes -- indeed, I think *NO* implementation would just wait until the last minute to refresh them. Is there something I'm missing? 2) Multiple IA_PD looks unnecessarily complex. Are there any valid reasons why it wouldn't be just enough to have only one IA_PD per requesting router? (The option to and subsequent complexity of) generating one for each interface seems like a completely unnecessary feature to me -- it's the router which should be doing prefix delegation to it's downstream interfaces! The only feature I can quickly think of which could profit from this is kind of "shared routers" where the connected interfaces are separate administrative entities with differently configured properties at the ISP. This seems questionable to me, a case for manual configuration or "advanced prefix delegation" to me. So, I think the possibility to do prefix delegation in more complex ways than really necessary should be seriously considered. Keep it Simple, Stupid would be a good rule. 3) One item that may also need some consideration is the option to let the requesting router give its preference to some values (prefix length, lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not sure of the usefulness of these, really. In the real world, I think ISP's set them, either to some values communicated off-band, or otherwise. The complexity required (policy, policy,...) when the delegating router must decide whether it can agree to the requested values seems like a big hit. I'm not really sure whether it's worth it, even though it may offer some flexibility for some corner cases. The only commonly used one I could think of would be whether the customer wants _single_ /64 (for the only one subnet!) or whole /48 -- seems like a heavy baggage for that. 4) As one who hasn't really read DHCPv6 specification, the spec was confusing as it introduced options and code values, and reused ones from DHCPv6 quite liberally (more of this below in detailed comments). I would have hoped for a bit clearer picture of elements associated with DHCP prefix delegation. 5) as above, there doesn't seem to be clear structure to the document when specifying the DHCPv6 PD-specific options (and different DHCPv6 options altogether) [sections 8-9, mostly]: this makes it rather difficult to follow the which options include which options, what options may be embedded in which, etc. This may partially be due to the fact I'm not so familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was missing. ==> in consequence I think there are at least two items, 1-3 which need some thought (if they haven't already been brought up and discussed), and at least 4-5 which would clarify the specification which are IMO very important in conveying the right message. As for more detailed comments...: Identity Association for Prefix Delegation (IA_PD) A collection of prefixes assigned to the requesting router. Each IA_PD has an associated IAID. ==> first use of "IAID", so spell it out, or even put is as an item in the terminology, as it keeps cropping up all the time. 4. Model and Applicability ==> the middle/latter part of this paragraph could be reorganized/reworded a bit to say that the model described there is indeed just an example; perhaps break off starting at page 5 as a separate sub-section? The delegating router chooses prefix(es) for delegation, and returns the prefix(es) to the requesting router. ==> the use of "returns the prefix(es)" seems slightly ambiguous -- could one read that and get a picture that the delegator gives back the same prefixes requested? Did I misunderstand, or did you mean along the lines of "responds with prefixes delegated to the requesing router" ? Figure 1 illustrates a network architecture in which prefix delegation would be used. ==> s/would/could/ ? The IAID uniquely identifies the IA_PD and must be chosen to be unique among the IA_PD IDs on the requesting router. ==> s/IDs/IAIDs/ ? option-code: OPTION_IA_PD (TBD) option-length: 12 + length of IA_PD-options field. ==> is it necessary to say how the option-code is stored/transported (signed/unsigned) ? I guess this is clear enough? ==> length of IA_PD-options field in which units? Octets, seems likely? ==> same issues in sect 9 T1 The time at which the requesting router contacts T2 The time at which the requesting router contacts ==> s/contacts/should contact/ or even "is instructed to contact" IA_PD-options Options associated with this IA_PD. The IA_PD-options field encapsulates those options that are specific to this IA_PD. For example, all of the IA_PD Prefix Options carrying the prefixes associated with this IA_PD are in the IA_PD-options field. ==> one should refer to the next section and explain that currently, only IA_PD Prefix option is defined? (I'd structure section 9 maybe differently: like "IA_PD options" as the main section title, and the current one as a subsection, but some other clarification would also be ok). In a message sent by a delegating router to a requesting router, the requesting router MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. ==> the first part of the sentence is awkward, did you mean something like "In case the message sent by the delegating router included non-zero T1 or T2, the parameters MUST be used" ? The status of any operations involving this IA_PD Prefix option is indicated in a Status Code option in the IAprefix-options field. ==> Status Code options haven't been explained. The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, ==> where is the defintion of NoPrefixAvail or other codes? message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID. ==> DUID used for the first time (inherited from DHCPv6 spec I think), spell it out? ==> all in all, I think one should have a better picture which kinds of options from DHCPv6 spec which aren't mentioned in the draft are ok (or if some aren't applicable) -- or at least refer to those in the previous sections. Each prefix has valid and preferred lifetimes whose duration is ==> s/duration is/durations are/ When a requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router in Figure 1 were delegated 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber network. ==> I'm not sure if the first sentence is entirely accurate. One could use prefix delegation to get multiple /64's directly from your ISP, then extra bits wouldn't be needed at all. When a delegating router receives a Request message from a requesting router that contains an IA_PD option, and the delegating router is authorised to delegate prefix(es) to the requesting router, the delegating router selects the prefix(es) to be delegated to the requesting router. The mechanism through which the delegating router selects prefix(es) for delegation is not specified in this document. Section 10.2 gives examples of ways in which a delegating router might select the prefix(es) to be delegated to a requesting router. A delegating router examines the prefix(es) identified in IA_PD Prefix options (in an IA_PD option) in Renew and Rebind messages and responds according to the current status of the prefix(es). [...] ==> These paragraph deal with a different message types and situations, etc., so separating them more clearly in the text would be useful (start using a similar sentence or whatever). ==> same goes in the next paragraph 14. Security Considerations ==> personally I'm rather worried about the requestor being able to give "guidance" to the delegator what on what it wants. Unreliable input could lead to bad results in an implementation which hasn't been done carefully (requesting link/site-local prefixes which don't exist, effect of bogus prefixlengths etc.etc.). [more of this was above] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 22 14:31:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MMVT7f025037; Sat, 22 Feb 2003 14:31:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1MMVTs8025036; Sat, 22 Feb 2003 14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1MMVQ7f025029 for ; Sat, 22 Feb 2003 14:31:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1MMVZVL027749 for ; Sat, 22 Feb 2003 14:31:35 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17267 for ; Sat, 22 Feb 2003 15:31:30 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 22:31:29 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 22:31:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 22:31:28 Z Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Feb 2003 22:31:28 Z Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h1MMV9u00749 for ; Sat, 22 Feb 2003 17:31:10 -0500 (EST) Date: Sat, 22 Feb 2003 17:31:06 -0500 From: Marc Blanchet To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" Message-Id: <879340000.1045953066@classic.viagenie.qc.ca> In-Reply-To: <5.1.0.14.2.20030221102512.03416e18@mail.windriver.com> References: <5.1.0.14.2.20030221102512.03416e18@mail.windriver.com> X-Mailer: Mulberry/3.0.0b12 (Linux/x86) MIME-Version: 1.0 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 h1MMVQ7f025030 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk to recall: - this draft is used by many organisations (both providers/R&E networks/enterprises) for address plans. - it is a way to manage efficiently the address space you get. - this draft was first presented 3 years ago and just need to be published, in order for organisations that want to use it to refer to a RFC instead of a draft that might disappear anytime. Marc. -- vendredi, février 21, 2003 10:43:12 -0500 Margaret Wasserman wrote/a écrit: > > Hi All, > > During the last call period for "A Flexible Method for > Managing the Assignment of Bytes of an IPv6 Address > Block", there was only one comment (attached). The > comment did not raise any specific technical issues with > the document, but it did question its usefulness. > > As I am sure many of you know, documents should only be > forwarded to the IESG for approval when there is a consensus > of the WG that the document is both technically sound and > useful. One ambivalent comment is not sufficient input to > demonstrate WG consensus for publishing this document. > > So, if there are people in the WG who do believe that this > document is both technically sound and useful and should be > sent to the IESG for publication as an Informational RFC, > could you please speak up? > > You can find the latest version of the document at: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt > > Thanks, > Margaret > > > >> To: Bob Hinden & Margaret Wasserman >> cc: ipng@sunroof.eng.sun.com >> Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the >> Assignment of Bytes of an IPv6 Address Block" >> >> >> On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote: >> > This is a IPv6 working group last call for comments on advancing the >> > following document as an Informational RFC: >> > >> > Title : A Flexible Method for Managing the Assignment >> > of Bits of an IPv6 Address Block >> > Author(s) : M. Blanchet >> > Filename : draft-ietf-ipv6-ipaddressassign-06.txt >> > Pages : 8 >> > Date : 2003-1-6 >> >> >> I don't have problems with this, though I'm not sure how useful this is >> for most (but for some, certainly). >> >> >> A point I've raised in the past is, most operators are not really >> interested in optimizing the address assignments on a bit level (provided >> that the number of customers is not so high it would be required). >> Rather, here we do so with nibbles. Those are easier to calculate in the >> head and work better with reverse DNS delegations too. >> >> >> But I'm not sure whether this kind of "coarser approach for flexible >> assignment" calls for some text or not. A mention at most, I think. >> What do others feel? >> >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 22 17:08:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1N18I7f025511; Sat, 22 Feb 2003 17:08:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1N18IjT025510; Sat, 22 Feb 2003 17:08:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1N18E7f025503 for ; Sat, 22 Feb 2003 17:08:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1N18OVK000975 for ; Sat, 22 Feb 2003 17:08:24 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15068 for ; Sat, 22 Feb 2003 18:08:17 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 01:08:16 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 01:08:16 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 01:08:15 Z Received: from imo-m08.mx.aol.com (imo-m08.mx.aol.com [64.12.136.163]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 01:08:14 Z Received: from Rich3800@aol.com by imo-m08.mx.aol.com (mail_out_v34.21.) id 1.a8.18c668d7 (15862) for ; Sat, 22 Feb 2003 20:08:07 -0500 (EST) Received: from aol.com ([12.108.37.109]) by air-id06.mx.aol.com (v90_r2.5) with ESMTP id MAILINID61-0222200807; Sat, 22 Feb 2003 20:08:07 -0500 Message-Id: <3E581D72.5040709@aol.com> Date: Sat, 22 Feb 2003 20:01:38 -0500 From: rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Linux SuSe 8.1 Pro Mrouter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What do I need to do to set up a SuSE Linux 8.1 Pro machine as an IPv6 multicast router (mrouter)? Can it be done with YAST? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 23 07:25:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NFPi7f027379; Sun, 23 Feb 2003 07:25:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1NFPiKe027378; Sun, 23 Feb 2003 07:25:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NFPe7f027371 for ; Sun, 23 Feb 2003 07:25:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1NFPnVK006875 for ; Sun, 23 Feb 2003 07:25:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15278 for ; Sun, 23 Feb 2003 08:25:43 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 15:25:41 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 15:25:39 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 15:25:38 Z Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 15:25:38 Z Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 23 Feb 2003 07:25:40 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Feb 2003 07:25:38 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 23 Feb 2003 07:25:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 3041 clarification requested Date: Sun, 23 Feb 2003 07:25:37 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3041 clarification requested Thread-Index: AcLU5pQt1t/wcnYNTvSSoF8dC36ZTAGaOc8A From: "Richard Draves" To: "JINMEI Tatuya / ????" Cc: "IPV6 WG" X-OriginalArrivalTime: 23 Feb 2003 15:25:37.0644 (UTC) FILETIME=[D113F2C0:01C2DB4F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1NFPf7f027372 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You do not generate link-local addresses for the new IIDs. And not > > site-local either. Just global addresses. > > Why not for site-local addresses? There's no technical reason you couldn't generate temporary link-local or site-local addresses. We felt that within a link/site, privacy is not so important and so better to avoid the additional overhead. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 23 09:11:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NHBU7f028318; Sun, 23 Feb 2003 09:11:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1NHBUGT028317; Sun, 23 Feb 2003 09:11:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NHBQ7f028307 for ; Sun, 23 Feb 2003 09:11:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1NHBZVL027272 for ; Sun, 23 Feb 2003 09:11:35 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04284 for ; Sun, 23 Feb 2003 10:11:28 -0700 (MST) From: juha.wiljakka@nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 16:09:44 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 16:08:08 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 16:09:43 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 16:09:42 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1NGChm12322 for ; Sun, 23 Feb 2003 18:12:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Feb 2003 18:09:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 18:09:38 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 18:09:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Sun, 23 Feb 2003 18:09:37 +0200 Message-Id: <245DBCAEEC4F074CB77B3F984FF9834F0193C272@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLaZZynvrulm453S7+HDXpNQWfSyQA66Q7Q To: Cc: , , X-OriginalArrivalTime: 23 Feb 2003 16:09:37.0984 (UTC) FILETIME=[F6D7DC00:01C2DB55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1NHBR7f028308 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all! Even though I find standardizing "stateless DNS discovery" in the IPv6 wg very important, I find this DHCPv6 option useful. So I also support moving it forward. 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 Sun Feb 23 10:02:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NI217f029091; Sun, 23 Feb 2003 10:02:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1NI21HM029090; Sun, 23 Feb 2003 10:02:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NI1w7f029083 for ; Sun, 23 Feb 2003 10:01:58 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1NI26VK028530 for ; Sun, 23 Feb 2003 10:02:06 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09377 for ; Sun, 23 Feb 2003 10:02:00 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:02:00 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:01:59 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:01:59 Z Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:01:59 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id D44221C00D9B; Sun, 23 Feb 2003 13:01:55 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id XAA24919; Sun, 23 Feb 2003 23:31:18 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" , "'Ralph Droms'" Cc: , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Sun, 23 Feb 2003 23:30:36 +0530 Message-Id: <000601c2db65$78a62750$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka See my reply inline. ~Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Sunday, February 23, 2003 2:27 AM > To: Ralph Droms > Cc: dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > On Tue, 11 Feb 2003, Ralph Droms wrote: > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > describes new DHCPv6 > > options and a mechanism through which a "delegating router" > (e.g., an ISP > > aggregation device) can assign and delegate one or more > prefixes to a > > "requesting router" (e.g., CPE). This draft is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- > prefix-delegation-02.txt > > A few comments. > > Bigger issues -- I'm sorry for bringing them up so late > (relatively), but > I haven't really thought/read about the big picture, before. > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > mostly redundant -- the requesting router should just take > the minimum of > lifetimes of the prefixes, calculate it in the same fashion, > that's it. > Of course, there is an assumption (which doesn't seem to be properly > addressed!) that the requesting router is free to refresh the > delegation > when it feels right, even every hour, day, month etc. without > regard to > the lifetimes -- indeed, I think *NO* implementation would > just wait until > the last minute to refresh them. > > Is there something I'm missing? Normally, T1 will be assigned with a value which is 0.5 times the shortest preferred lifetime of the prefixes in the IA_PD. This means you have enough time till the expiration of lifetimes of the prefixes. > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > reasons why it wouldn't be just enough to have only one IA_PD per > requesting router? (The option to and subsequent complexity of) > generating one for each interface seems like a completely unnecessary > feature to me -- it's the router which should be doing prefix > delegation > to it's downstream interfaces! Seperate IA_PDs for every downstream interface is not mandatory. Look at the following text: One IA_PD can be associated with the requesting router, with a set of interfaces or with exactly one interface. A requesting router must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the delegating router. Its requesting routers' wish to have single or multiple IA_PDs. > > The only feature I can quickly think of which could profit > from this is > kind of "shared routers" where the connected interfaces are separate > administrative entities with differently configured > properties at the ISP. Exactly. That's the case. When the downstreaming interfaces are served my multiple ISPs, you need multiple IA_PDs. > This seems questionable to me, a case for manual configuration or > "advanced prefix delegation" to me. > > So, I think the possibility to do prefix delegation in more > complex ways > than really necessary should be seriously considered. Keep it Simple, > Stupid would be a good rule. Generate IA_PDs such that every ISP is associtated with a single IA_PD. I think, this is the simplest method possible. > > 3) One item that may also need some consideration is the > option to let the > requesting router give its preference to some values (prefix length, > lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not > sure of the usefulness of these, really. In the real world, > I think ISP's > set them, either to some values communicated off-band, or > otherwise. The > complexity required (policy, policy,...) when the delegating > router must > decide whether it can agree to the requested values seems > like a big hit. > I'm not really sure whether it's worth it, even though it may > offer some > flexibility for some corner cases. The only commonly used one I could > think of would be whether the customer wants _single_ /64 > (for the only > one subnet!) or whole /48 -- seems like a heavy baggage for that. Yes. I too agree with you. If there is no pre-configured information for the requesting router in the delegating router, it wont be able to to know whether the requesting routers needs /48 or /64 bit prefix. Probably, the solution would be, in the request message, the requesting routers can specify prefix length it prefers. But, the server MUST process that and delegate prefixes accordingly, else it should send back NoPrefixAvail. > > 4) As one who hasn't really read DHCPv6 specification, the spec was > confusing as it introduced options and code values, and > reused ones from > DHCPv6 quite liberally (more of this below in detailed > comments). I would > have hoped for a bit clearer picture of elements associated with DHCP > prefix delegation. > > 5) as above, there doesn't seem to be clear structure to the > document when > specifying the DHCPv6 PD-specific options (and different > DHCPv6 options > altogether) [sections 8-9, mostly]: this makes it rather difficult to > follow the which options include which options, what options may be > embedded in which, etc. This may partially be due to the > fact I'm not so > familiar with DHCPv6, but some kind of "hierarchy" or "big > picture" was > missing. > > ==> in consequence I think there are at least two items, 1-3 > which need > some thought (if they haven't already been brought up and > discussed), and > at least 4-5 which would clarify the specification which are IMO very > important in conveying the right message. > > As for more detailed comments...: > > Identity Association for Prefix Delegation (IA_PD) A collection of > prefixes assigned to the requesting > router. Each > IA_PD has an associated IAID. > > ==> first use of "IAID", so spell it out, or even put is as > an item in the > terminology, as it keeps cropping up all the time. > > 4. Model and Applicability > > ==> the middle/latter part of this paragraph could be > reorganized/reworded > a bit to say that the model described there is indeed just an > example; > perhaps break off starting at page 5 as a separate sub-section? > > The delegating router chooses prefix(es) > for delegation, and returns the prefix(es) to the > requesting router. > > ==> the use of "returns the prefix(es)" seems slightly > ambiguous -- could > one read that and get a picture that the delegator gives back > the same > prefixes requested? Did I misunderstand, or did you mean > along the lines > of "responds with prefixes delegated to the requesing router" ? > > Figure 1 illustrates a network architecture in which prefix > delegation would be used. > > ==> s/would/could/ ? > > The IAID uniquely identifies the IA_PD and must be chosen to be > unique among the IA_PD IDs on the requesting router. > > ==> s/IDs/IAIDs/ ? > > option-code: OPTION_IA_PD (TBD) > > option-length: 12 + length of IA_PD-options field. > > ==> is it necessary to say how the option-code is stored/transported > (signed/unsigned) ? I guess this is clear enough? > > ==> length of IA_PD-options field in which units? Octets, > seems likely? > > ==> same issues in sect 9 > > T1 The time at which the requesting router contacts > T2 The time at which the requesting router contacts > > ==> s/contacts/should contact/ or even "is instructed to contact" > > IA_PD-options Options associated with this IA_PD. > > The IA_PD-options field encapsulates those options that > are specific > to this IA_PD. For example, all of the IA_PD Prefix > Options carrying > the prefixes associated with this IA_PD are in the IA_PD-options > field. > > ==> one should refer to the next section and explain that > currently, only > IA_PD Prefix option is defined? (I'd structure section 9 maybe > differently: like "IA_PD options" as the main section title, and the > current one as a subsection, but some other clarification > would also be > ok). > > In a message sent > by a delegating router to a requesting router, the > requesting router > MUST use the values in the T1 and T2 fields for the T1 and T2 > parameters. > > ==> the first part of the sentence is awkward, did you mean > something like > "In case the message sent by the delegating router included > non-zero T1 or > T2, the parameters MUST be used" ? > > The status of any operations involving this IA_PD Prefix > option is > indicated in a Status Code option in the IAprefix-options field. > > ==> Status Code options haven't been explained. > > The requesting router MUST ignore any Advertise message > that includes > a Status Code option containing the value NoPrefixAvail, > > ==> where is the defintion of NoPrefixAvail or other codes? > > message for the user, a Server Identifier option with the > delegating > router's DUID and a Client Identifier option with the requesting > router's DUID. > > ==> DUID used for the first time (inherited from DHCPv6 spec > I think), > spell it out? > > ==> all in all, I think one should have a better picture > which kinds of > options from DHCPv6 spec which aren't mentioned in the draft > are ok (or if > some aren't applicable) -- or at least refer to those in the previous > sections. > > Each prefix has valid and preferred lifetimes whose duration is > > ==> s/duration is/durations are/ > > When a requesting router subnets a delegated prefix, it must assign > additional bits to the prefix to generate unique, longer prefixes. > For example, if the requesting router in Figure 1 were delegated > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:0:2::/64 for assignment to the two links in the > subscriber > network. > > ==> I'm not sure if the first sentence is entirely accurate. > One could > use prefix delegation to get multiple /64's directly from > your ISP, then > extra bits wouldn't be needed at all. Instead of getting multiple /64 prefixes, if the requesting router belonged to a site with huge number of links, then it can obtain /48 prefix and distribute it among the links. > > When a delegating router receives a Request message from a > requesting > router that contains an IA_PD option, and the delegating router is > authorised to delegate prefix(es) to the requesting router, the > delegating router selects the prefix(es) to be delegated to the > requesting router. The mechanism through which the > delegating router > selects prefix(es) for delegation is not specified in this > document. > Section 10.2 gives examples of ways in which a delegating router > might select the prefix(es) to be delegated to a requesting router. > > A delegating router examines the prefix(es) identified in IA_PD > Prefix options (in an IA_PD option) in Renew and Rebind > messages and > responds according to the current status of the prefix(es). [...] > > ==> These paragraph deal with a different message types and > situations, > etc., so separating them more clearly in the text would be > useful (start > using a similar sentence or whatever). > > ==> same goes in the next paragraph > > 14. Security Considerations > > ==> personally I'm rather worried about the requestor being > able to give > "guidance" to the delegator what on what it wants. > Unreliable input could > lead to bad results in an implementation which hasn't been > done carefully > (requesting link/site-local prefixes which don't exist, > effect of bogus > prefixlengths etc.etc.). [more of this was above] > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 23 10:34:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NIY87f029497; Sun, 23 Feb 2003 10:34:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1NIY8SV029496; Sun, 23 Feb 2003 10:34:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1NIY57f029489 for ; Sun, 23 Feb 2003 10:34:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1NIYDVL009495 for ; Sun, 23 Feb 2003 10:34:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27884 for ; Sun, 23 Feb 2003 11:34:08 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:34:07 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:34:06 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:34:06 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Feb 2003 18:34:06 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1NIPjG13443; Sun, 23 Feb 2003 20:25:45 +0200 Date: Sun, 23 Feb 2003 20:25:45 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <000601c2db65$78a62750$38e62a0f@nt23056> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some comments inline. On Sun, 23 Feb 2003, Vijayabhaskar A K wrote: > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > mostly redundant -- the requesting router should just take the minimum > > of lifetimes of the prefixes, calculate it in the same fashion, that's > > it. Of course, there is an assumption (which doesn't seem to be > > properly addressed!) that the requesting router is free to refresh the > > delegation when it feels right, even every hour, day, month etc. > > without regard to the lifetimes -- indeed, I think *NO* implementation > > would just wait until the last minute to refresh them. > > > > Is there something I'm missing? > > Normally, T1 will be assigned with a value which is 0.5 times the > shortest preferred lifetime of the prefixes in the IA_PD. This > means you have enough time till the expiration of lifetimes of the > prefixes. That doesn't answer the real question. That is, the requesting router is in charge of all the prefixes until they expire. The robust requesting router implementation will perform some sane refreshing of these bindings way before they expire, even periodically. Thus, I fail to see any reason why these values would have to be communicated from the delegator. > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > reasons why it wouldn't be just enough to have only one IA_PD per > > requesting router? (The option to and subsequent complexity of) > > generating one for each interface seems like a completely unnecessary > > feature to me -- it's the router which should be doing prefix > > delegation > > to it's downstream interfaces! > > Seperate IA_PDs for every downstream interface is not mandatory. > Look at the following text: > > One IA_PD can be associated > with the requesting router, with a set of interfaces or with exactly > one interface. A requesting router must create at least one distinct > IA_PD. It may associate a distinct IA_PD with each of its downstream > network interfaces and use that IA_PD to obtain a prefix for that > interface from the delegating router. > > Its requesting routers' wish to have single or multiple IA_PDs. I know it is not mandatory: but it seems (mostly) unnecessary to me, which was the real point. > > The only feature I can quickly think of which could profit > > from this is > > kind of "shared routers" where the connected interfaces are separate > > administrative entities with differently configured > > properties at the ISP. > > Exactly. That's the case. > When the downstreaming interfaces are served my multiple ISPs, > you need multiple IA_PDs. Prefix delegation by DHCP is not meant to be all-purpose-zero-configuration tool for routers, I think. This seems conflicting -- a fringe case which should not came up. Better would be just require that the requesting router will get a delegation from all the ISP's for itself, and subnet accordingly. If the following does not apply, it seems to me that there must be routers connected to the downstreaming interfaces -- which in turn could perform prefix delegation directly from the ISP, the first router acting as a relay. Doesn't seem to be need for this.. > > This seems questionable to me, a case for manual configuration or > > "advanced prefix delegation" to me. > > > > So, I think the possibility to do prefix delegation in more > > complex ways > > than really necessary should be seriously considered. Keep it Simple, > > Stupid would be a good rule. > > Generate IA_PDs such that every ISP is associtated with a single > IA_PD. I think, this is the simplest method possible. Seems wrong to me: An IA_PD is a construct through which a delegating router and a requesting router can identify, group and manage a set of related IPv6 prefixes. and: Identity Association for Prefix Delegation (IA_PD) A collection of prefixes assigned to the requesting router. Each IA_PD has an associated IAID. ==> the model appears to be, to me, that the requesting router makes an association with *one* delegating router. In that case, multiple IA_PD's for multiple seem unnecessary. If this is not the case, the applicability section needs to be worked out a bit more. Also, then I can't help wondering what multiple prefixes are for. Why would anyone (except for bogus /64 for every downstream link -delegating requests) want multiple prefixes? (note: site-local is not applicable, different admin domains.) Regardless of that, I'm not sure how the requesting router would discover more of these delegating routers -- how would they be connected? Which kind of infrastructure would typically be between requesting router and multiple delegating routers? > > 3) One item that may also need some consideration is the option to let > > the requesting router give its preference to some values (prefix > > length, lifetimes, IAprefix-options contents (maybe?), the prefixes). > > I'm not sure of the usefulness of these, really. In the real world, I > > think ISP's set them, either to some values communicated off-band, or > > otherwise. The complexity required (policy, policy,...) when the > > delegating router must decide whether it can agree to the requested > > values seems like a big hit. I'm not really sure whether it's worth > > it, even though it may offer some flexibility for some corner cases. > > The only commonly used one I could think of would be whether the > > customer wants _single_ /64 (for the only one subnet!) or whole /48 -- > > seems like a heavy baggage for that. > > Yes. I too agree with you. If there is no pre-configured information > for the requesting router in the delegating router, it wont > be able to to know whether the requesting routers needs /48 or > /64 bit prefix. > > Probably, the solution would be, in the request message, the requesting > routers can specify prefix length it prefers. But, the server MUST > process that and delegate prefixes accordingly, else it should > send back NoPrefixAvail. I agree that for certain requested values, the outcome would get very confusing for the requesting router if the delegating router could not fullfill these requirements. But the point was different: I think the whole "preference for X" model seems mostly unnecessary. > > One could use prefix delegation to get multiple /64's directly from > > your ISP, then extra bits wouldn't be needed at all. > > Instead of getting multiple /64 prefixes, if the requesting router > belonged to a site with huge number of links, then it can obtain /48 > prefix and distribute it among the links. I totally agree with that (that's the sensible thing to do!), but the first sentence was not accurate, as you don't split /64 prefixes *IF* you'd do it nonetheless. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 00:26:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1O8Qi7f002298; Mon, 24 Feb 2003 00:26:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1O8Qiqd002296; Mon, 24 Feb 2003 00:26:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1O8Qd7f002278 for ; Mon, 24 Feb 2003 00:26:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1O8QmVK002434 for ; Mon, 24 Feb 2003 00:26:48 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26838 for ; Mon, 24 Feb 2003 01:26:42 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 08:26:16 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 08:24:36 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 08:26:14 Z Received: from dhcp-168-17-124.autonomica.se ([130.244.10.138] [130.244.10.138]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 08:26:12 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O8RMif009799; Mon, 24 Feb 2003 09:27:22 +0100 (CET) Date: Mon, 24 Feb 2003 09:27:21 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030222101339.D61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> There is no technical reason why a single service provider network >>> can >>> do better than a similar network that consists of several smaller > >> See Abha and Craigs paper on convergence of BGP. Personally I would go >> for a large provider with multiple connections. > > Based on this paper? What I see is rarely as bad as what they describe. > However, I had the chance to experiment a little with revoking a > longer prefix and then see how soon the shorter prefix would "catch" > the > traffic a while back, and this was certainly interesting: the state > goes > back and forth between "working" and "not working" several times over > the course of two minutes. But simple failover is usually pretty fast. My experience is different, and I believe many others share that. But this will always be different for everyone. >> Last fall I was invited to a conference in Sweden to debate >> multihoming >> and the enterprise. Before me was this enterprise IT manager who >> showed >> how much more resilient his network was with two BGP sessions. While >> he >> talked I checked his announcements just to find that one of the >> providers bought transit from the other. You can't buy clue. > > You can buy a good book that explains it all. :-) > > Did you check to see if the second ISPs also had additional upstreams? Yes they did. And they bought transit from the first provider. > >>> But IGPs have the same >>> fundamental problem (although the details may differ). OSPF for >>> instance takes 40 seconds to detect a dead circuit. > >> there was a fix proposed in San Diego (although for IS-IS) but that >> was >> voted down. There was pros and cons. > > Just type: > > ip ospf hello-interval 1 > ip ospf dead-interval 3 > > But do it on ALL your boxes in the subnet or you'll live to regret it. This I thought was more or less standard. I was talking about less than 100ms convergence. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 05:02:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OD2A7f003199; Mon, 24 Feb 2003 05:02:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OD2An1003198; Mon, 24 Feb 2003 05:02:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OD277f003191 for ; Mon, 24 Feb 2003 05:02:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OD2FVK010977 for ; Mon, 24 Feb 2003 05:02:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21262 for ; Mon, 24 Feb 2003 06:02:09 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:02:09 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:02:09 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:02:08 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:02:08 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OD25Nh008115; Mon, 24 Feb 2003 08:02:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-204.cisco.com [10.82.224.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02946; Mon, 24 Feb 2003 08:02:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 08:00:00 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reminder and note: there has been not response to this WG last call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 24 05:51:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ODpd7f003535; Mon, 24 Feb 2003 05:51:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1ODpdCR003534; Mon, 24 Feb 2003 05:51:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1ODpa7f003527 for ; Mon, 24 Feb 2003 05:51:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1ODpiVL012525 for ; Mon, 24 Feb 2003 05:51:44 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06992 for ; Mon, 24 Feb 2003 06:51:38 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:51:36 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:49:28 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:51:06 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 13:51:05 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1ODp2JR011295; Mon, 24 Feb 2003 08:51:02 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA04960; Mon, 24 Feb 2003 08:51:02 -0500 (EST) Message-Id: <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 08:51:01 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please ignore the first sentence of this reminder - it was queued for transmission before the round of discussion that began at the end of last week... - Ralph At 08:00 AM 2/24/2003 -0500, Ralph Droms wrote: >Reminder and note: there has been not response to this WG last >call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt >and reply with comments. If you recommend the document for advancement >without revision, please respond with a quick acknowledgment. No response >will be interpreted as a lack of support for advancing the document. > >----- > >This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" >. The last call will >conclude on Friday, 2/28. > >Note that this is a parallel WG last call in the dhc and ipv6 WGs. > >draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 >options and a mechanism through which a "delegating router" (e.g., an ISP >aggregation device) can assign and delegate one or more prefixes to a >"requesting router" (e.g., CPE). This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > >- 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 Mon Feb 24 07:01:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OF1j7f003926; Mon, 24 Feb 2003 07:01:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OF1iTI003925; Mon, 24 Feb 2003 07:01:44 -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.8+Sun/8.12.8) with ESMTP id h1OF1e7f003918 for ; Mon, 24 Feb 2003 07:01:41 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1OF1gP20883; Mon, 24 Feb 2003 16:01:42 +0100 (MET) Date: Mon, 24 Feb 2003 15:57:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Mika Liljeberg Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1045849238.22159.30.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Depends what happens when the binding times out and > > needs to be refreshed/re-established. > > MIPv6 assumes that it can just redo the RR exchange and > > still end up sending to the same host. That isn't the case for > > anycast since the anycast address identifies more of a service than a host. > > Thus to make it more likely that the transport connection survive > > routing changes it makes sense to get the transport connection basically > > be redirected to use a unicast member of the anycast group. > > I don't know that the binding needs to have a limited lifetime in this > case. It can be deleted when the TCP connection is closed (or via a > reference counting mechanism in case multiple connections can map to the > same binding). What about the case when you have UDP communication which needs to reach the same server? (or at least be notified when the anycast server changes). In that case you can't rely on the fact that the kernel has a single notion of active communication. 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 Mon Feb 24 07:07:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OF7N7f003963; Mon, 24 Feb 2003 07:07:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OF7Nxt003962; Mon, 24 Feb 2003 07:07:23 -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.8+Sun/8.12.8) with ESMTP id h1OF7J7f003955 for ; Mon, 24 Feb 2003 07:07:20 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1OF7KP21136; Mon, 24 Feb 2003 16:07:20 +0100 (MET) Date: Mon, 24 Feb 2003 16:03:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Pekka Savola Cc: Erik Nordmark , 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 > For connection-less protocols, source address should not matter, that > much. The fact that UDP is a connection-less layer 4 protocol doesn't mean that there aren't protocols above it which assume that they continue to talk to the same peer (until communication fails). 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 Mon Feb 24 07:32:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OFW67f004247; Mon, 24 Feb 2003 07:32:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OFW6ro004246; Mon, 24 Feb 2003 07:32:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OFW37f004239 for ; Mon, 24 Feb 2003 07:32:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OFWBVL001689 for ; Mon, 24 Feb 2003 07:32:11 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12378 for ; Mon, 24 Feb 2003 07:32:04 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 15:32:01 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Mon, 24 Feb 2003 15:31:59 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Mon, 24 Feb 2003 15:31:59 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP; Mon, 24 Feb 2003 15:31:58 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1OFVuc20368; Mon, 24 Feb 2003 17:31:56 +0200 Date: Mon, 24 Feb 2003 17:31:56 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: a few comments on anycast mechanisms 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, 24 Feb 2003, Erik Nordmark wrote: > > For connection-less protocols, source address should not matter, that > > much. > > The fact that UDP is a connection-less layer 4 protocol doesn't mean > that there aren't protocols above it which assume that they > continue to talk to the same peer (until communication fails). This can also be turned the other way around: for such protocols, connection failure signals the need to re-establish this "pseudo-connection". This is a big problem only if the anycast group is flapping severely, it seems to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 08:00:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OG017f004704; Mon, 24 Feb 2003 08:00:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OG01FU004703; Mon, 24 Feb 2003 08:00:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OFxv7f004696 for ; Mon, 24 Feb 2003 07:59:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OG05VL008786 for ; Mon, 24 Feb 2003 08:00:05 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25950 for ; Mon, 24 Feb 2003 08:59:59 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 15:59:58 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 15:59:57 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 15:59:56 Z Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 15:59:56 Z Received: from tom3 (usermd53.uk.uudial.com [62.188.120.250]) by colossus.systems.pipex.net (Postfix) with SMTP id 8C4CD160001EC; Mon, 24 Feb 2003 15:59:46 +0000 (GMT) Message-Id: <022e01c2dc1d$76f49d20$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: "Pekka Savola" , "Alan E. Beard" , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Date: Mon, 24 Feb 2003 15:55:16 -0000 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To talk about resilience is a snare for the unwary until you specify what you are providing resilience against. The large enterprises I work with have a simple policy, set by the non-technicians who run the organisation; no single point of failure. That doesn't mean no single point of failure in the ISP - that is up to the management of the ISP - but no single failure in the parts the enterprise management is accountable for, such as the links to the ISP. So if one ISP piggy backs on another, that is the choice of the management of the ISP and so not their responsibility. In the non-IP world, that invariably means taking bandwidth, basic carrier services, to two different telcos, coming out of different parts of the site, to different exchanges, perhaps with different media (copper and fibre, fibre and wireless), not having a power supply (eg local electricity supplier) in common. If in the centre of the world these feeds share a fibre, that is the telco's concern, not the enterprise's. The enterprise should ensure that the telcos do not share a local exchange or fibre to the site but no more than that. This is a system that has evolved over decades with much pain but it does work well because the bulk of failures - some surveys put it as high as 95% - occur within the 'last mile' and that is what this gives resilience against. IP? same difference. It is the links to the ISPs' points of presence (obviously not co-located) that are the primary concern of the enterprise management. If ISPs share a resource, which in a sense every ISP does because there is a single world-wide BGP RIB, then that is the responsibility of the ISP. So multi-homing is a must. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Kurt Erik Lindqvist To: Iljitsch van Beijnum Cc: Pekka Savola ; Alan E. Beard ; Tim Chown ; ipng@sunroof.eng.sun.com ; multi6@ops.ietf.org Date: 24 February 2003 08:29 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] >>>> There is no technical reason why a single service provider network >>>> can >>>> do better than a similar network that consists of several smaller >> >>> See Abha and Craigs paper on convergence of BGP. Personally I would go >>> for a large provider with multiple connections. >> >> Based on this paper? What I see is rarely as bad as what they describe. >> However, I had the chance to experiment a little with revoking a >> longer prefix and then see how soon the shorter prefix would "catch" >> the >> traffic a while back, and this was certainly interesting: the state >> goes >> back and forth between "working" and "not working" several times over >> the course of two minutes. But simple failover is usually pretty fast. > >My experience is different, and I believe many others share that. But >this will always be different for everyone. > >>> Last fall I was invited to a conference in Sweden to debate >>> multihoming >>> and the enterprise. Before me was this enterprise IT manager who >>> showed >>> how much more resilient his network was with two BGP sessions. While >>> he >>> talked I checked his announcements just to find that one of the >>> providers bought transit from the other. You can't buy clue. >> >> You can buy a good book that explains it all. :-) >> >> Did you check to see if the second ISPs also had additional upstreams? > >Yes they did. And they bought transit from the first provider. > >> >>>> But IGPs have the same >>>> fundamental problem (although the details may differ). OSPF for >>>> instance takes 40 seconds to detect a dead circuit. >> >>> there was a fix proposed in San Diego (although for IS-IS) but that >>> was >>> voted down. There was pros and cons. >> >> Just type: >> >> ip ospf hello-interval 1 >> ip ospf dead-interval 3 >> >> But do it on ALL your boxes in the subnet or you'll live to regret it. > >This I thought was more or less standard. I was talking about less than >100ms convergence. > >- kurtis - > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Mon Feb 24 09:40:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHeF7f005129; Mon, 24 Feb 2003 09:40:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OHeFpf005128; Mon, 24 Feb 2003 09:40:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHeB7f005121 for ; Mon, 24 Feb 2003 09:40:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OHeJVL007082 for ; Mon, 24 Feb 2003 09:40:19 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17032 for ; Mon, 24 Feb 2003 10:40:13 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:40:12 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:40:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:40:12 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:40:11 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C846C15210; Tue, 25 Feb 2003 02:40:16 +0900 (JST) Date: Tue, 25 Feb 2003 02:40:10 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 24 Feb 2003 08:51:01 -0500, >>>>> Ralph Droms said: > Please ignore the first sentence of this reminder - it was queued for > transmission before the round of discussion that began at the end of last > week... >> Reminder and note: there has been not response to this WG last >> call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt >> and reply with comments. If you recommend the document for advancement >> without revision, please respond with a quick acknowledgment. No response >> will be interpreted as a lack of support for advancing the document. I basically support the idea of the draft, but I have several issues to be discussed before advancing it. I'll re-read the latest revision and send a list of issues in a few days. 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 24 09:47:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHl27f005236; Mon, 24 Feb 2003 09:47:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OHl2QY005235; Mon, 24 Feb 2003 09:47:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHkx7f005228 for ; Mon, 24 Feb 2003 09:46:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OHl7VL009150 for ; Mon, 24 Feb 2003 09:47:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17031 for ; Mon, 24 Feb 2003 10:47:01 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:46:43 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:43:14 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:43:14 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:43:13 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OHh8Nh024277; Mon, 24 Feb 2003 12:43:09 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23894; Mon, 24 Feb 2003 12:43:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030224123058.03f484a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:43:06 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912992.27180.14.camel@devil> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 09:58:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHwT7f005687; Mon, 24 Feb 2003 09:58:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OHwSmW005686; Mon, 24 Feb 2003 09:58:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OHwP7f005679 for ; Mon, 24 Feb 2003 09:58:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OHwXVK022637 for ; Mon, 24 Feb 2003 09:58:33 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27456 for ; Mon, 24 Feb 2003 10:58:27 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 17:58:25 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP; Mon, 24 Feb 2003 17:58:20 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Mon, 24 Feb 2003 17:58:20 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP; Mon, 24 Feb 2003 17:58:19 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1OHwXaj013031; Mon, 24 Feb 2003 19:58:33 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1OHwUoJ013028; Mon, 24 Feb 2003 19:58:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: a few comments on anycast mechanisms From: Mika Liljeberg To: Erik Nordmark Cc: Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046109510.6109.13.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Feb 2003 19:58:30 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2003-02-24 at 16:57, Erik Nordmark wrote: > What about the case when you have UDP communication which needs to reach > the same server? (or at least be notified when the anycast server changes). > In that case you can't rely on the fact that the kernel has a single notion > of active communication. Well, this was only proposed for TCP. I'm not sure if we should consider something similar for UDP. Basically, UDP based protocols can be easily written to handle the peer address change on the application layer. However, if we want to support existing UDP applications that for example connect() their socket to a destination address, we'd need to device something similar for UDP as well. Do you think we need this? MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 10:29:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OITV7f006130; Mon, 24 Feb 2003 10:29:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OITV1D006129; Mon, 24 Feb 2003 10:29:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OITR7f006119 for ; Mon, 24 Feb 2003 10:29:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OITZVK002649 for ; Mon, 24 Feb 2003 10:29:35 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21453 for ; Mon, 24 Feb 2003 11:29:30 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 18:29:29 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 18:29:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 18:29:28 Z Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 18:29:28 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id DB9E61C0152D; Mon, 24 Feb 2003 10:29:25 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id XAA17328; Mon, 24 Feb 2003 23:58:49 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" Cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Mon, 24 Feb 2003 23:58:06 +0530 Message-Id: <001901c2dc32$7a55e400$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My comments inline.... ~ Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Sunday, February 23, 2003 11:56 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Some comments inline. > > On Sun, 23 Feb 2003, Vijayabhaskar A K wrote: > > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > > mostly redundant -- the requesting router should just > take the minimum > > > of lifetimes of the prefixes, calculate it in the same > fashion, that's > > > it. Of course, there is an assumption (which doesn't seem to be > > > properly addressed!) that the requesting router is free > to refresh the > > > delegation when it feels right, even every hour, day, month etc. > > > without regard to the lifetimes -- indeed, I think *NO* > implementation > > > would just wait until the last minute to refresh them. > > > > > > Is there something I'm missing? > > > > Normally, T1 will be assigned with a value which is 0.5 times the > > shortest preferred lifetime of the prefixes in the IA_PD. This > > means you have enough time till the expiration of lifetimes of the > > prefixes. > > That doesn't answer the real question. > > That is, the requesting router is in charge of all the > prefixes until they > expire. The robust requesting router implementation will > perform some > sane refreshing of these bindings way before they expire, even > periodically. > > Thus, I fail to see any reason why these values would have to be > communicated from the delegator. Yes, I agree that the it can refresh the bindings at any periodic intervals it want. But, what if the delegating router is dead and not responding at all? Hence, dhcpv6 provides you with two values: T1 -> This is the time at which the requesting router starts contacting the delegating router for the renewal of the lease... T2 -> If till the expiration of T2 it didn't get the response from the delegating router, it can contact any available dhcpv6 server to refresh its bindings. Ofcourse, the requesting router can generate these values itself. With DHCPv6 server sending T1 and T2 values, the requesting router dont need to recalculate the values again and again.. Trust the DHCPv6 server, the values provided by it makes the requesting router to refresh its bindings well before the expiry.. > > > > 2) Multiple IA_PD looks unnecessarily complex. Are there > any valid > > > reasons why it wouldn't be just enough to have only one IA_PD per > > > requesting router? (The option to and subsequent complexity of) > > > generating one for each interface seems like a completely > unnecessary > > > feature to me -- it's the router which should be doing prefix > > > delegation > > > to it's downstream interfaces! > > > > Seperate IA_PDs for every downstream interface is not mandatory. > > Look at the following text: > > > > One IA_PD can be associated > > with the requesting router, with a set of interfaces or > with exactly > > one interface. A requesting router must create at least > one distinct > > IA_PD. It may associate a distinct IA_PD with each of > its downstream > > network interfaces and use that IA_PD to obtain a prefix for that > > interface from the delegating router. > > > > Its requesting routers' wish to have single or multiple IA_PDs. > > I know it is not mandatory: but it seems (mostly) unnecessary > to me, which > was the real point. > > > > The only feature I can quickly think of which could profit > > > from this is > > > kind of "shared routers" where the connected interfaces > are separate > > > administrative entities with differently configured > > > properties at the ISP. > > > > Exactly. That's the case. > > When the downstreaming interfaces are served my multiple ISPs, > > you need multiple IA_PDs. > > Prefix delegation by DHCP is not meant to be > all-purpose-zero-configuration tool for routers, I think. > > This seems conflicting -- a fringe case which should not came up. > > Better would be just require that the requesting router will get a > delegation from all the ISP's for itself, and subnet accordingly. > > If the following does not apply, it seems to me that there > must be routers > connected to the downstreaming interfaces -- which in turn > could perform > prefix delegation directly from the ISP, the first router acting as a > relay. > > Doesn't seem to be need for this.. Need not be. Simple case is Home networks, they dont afford to have individual routers for every ISPs. They may need multiple ISPs for high availablity or some other reason. In this case, there will be only one border router with mutiple appliances/nodes in the downstreaming interfaces, which may span in one or more links. In this case, it needs to unique IA_PD for every ISP. > > > > This seems questionable to me, a case for manual configuration or > > > "advanced prefix delegation" to me. > > > > > > So, I think the possibility to do prefix delegation in more > > > complex ways > > > than really necessary should be seriously considered. > Keep it Simple, > > > Stupid would be a good rule. > > > > Generate IA_PDs such that every ISP is associtated with a single > > IA_PD. I think, this is the simplest method possible. > > Seems wrong to me: > > An IA_PD is a construct through which a delegating router and a > requesting router can identify, group and manage a set of related > IPv6 prefixes. > > and: > > Identity Association for Prefix Delegation (IA_PD) A > collection of > prefixes assigned to the requesting > router. Each > IA_PD has an associated IAID. > > ==> the model appears to be, to me, that the requesting > router makes an > association with *one* delegating router. In that case, > multiple IA_PD's > for multiple seem unnecessary. > > If this is not the case, the applicability section needs to > be worked out > a bit more. > > Also, then I can't help wondering what multiple prefixes are for. Why > would anyone (except for bogus /64 for every downstream link > -delegating > requests) want multiple prefixes? (note: site-local is not > applicable, > different admin domains.) May be for high availabilty, it may get prefixes from multiple ISPs. > > Regardless of that, I'm not sure how the requesting router > would discover > more of these delegating routers -- how would they be > connected? Which > kind of infrastructure would typically be between requesting > router and > multiple delegating routers? I beleive there will be unique dialup connection with each ISPs. > > > > 3) One item that may also need some consideration is the > option to let > > > the requesting router give its preference to some values (prefix > > > length, lifetimes, IAprefix-options contents (maybe?), > the prefixes). > > > I'm not sure of the usefulness of these, really. In the > real world, I > > > think ISP's set them, either to some values communicated > off-band, or > > > otherwise. The complexity required (policy, policy,...) when the > > > delegating router must decide whether it can agree to the > requested > > > values seems like a big hit. I'm not really sure whether > it's worth > > > it, even though it may offer some flexibility for some > corner cases. > > > The only commonly used one I could think of would be whether the > > > customer wants _single_ /64 (for the only one subnet!) or > whole /48 -- > > > seems like a heavy baggage for that. > > > > Yes. I too agree with you. If there is no pre-configured information > > for the requesting router in the delegating router, it wont > > be able to to know whether the requesting routers needs /48 or > > /64 bit prefix. > > > > Probably, the solution would be, in the request message, > the requesting > > routers can specify prefix length it prefers. But, the server MUST > > process that and delegate prefixes accordingly, else it should > > send back NoPrefixAvail. > > I agree that for certain requested values, the outcome would get very > confusing for the requesting router if the delegating router > could not > fullfill these requirements. > > But the point was different: I think the whole "preference > for X" model > seems mostly unnecessary. > > > One could use prefix delegation to get multiple /64's > directly from > > > your ISP, then extra bits wouldn't be needed at all. > > > > Instead of getting multiple /64 prefixes, if the requesting router > > belonged to a site with huge number of links, then it can obtain /48 > > prefix and distribute it among the links. > > I totally agree with that (that's the sensible thing to do!), but the > first sentence was not accurate, as you don't split /64 prefixes *IF* > you'd do it nonetheless. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 11:36:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJaw7f006933; Mon, 24 Feb 2003 11:36:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OJawjo006932; Mon, 24 Feb 2003 11:36:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJat7f006925 for ; Mon, 24 Feb 2003 11:36:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OJb3VK026232 for ; Mon, 24 Feb 2003 11:37:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07133 for ; Mon, 24 Feb 2003 12:36:57 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:58 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:56 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:55 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:55 Z Content-class: urn:content-classes:message Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Date: Mon, 24 Feb 2003 11:34:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C34@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" Thread-Index: AcLZkgbkegIa9L99Qq20VPzwRpGkWgCqSstA From: "Michel Py" To: "Erik Nordmark" Cc: "Alain Durand" , "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1OJat7f006926 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >>Michel Py wrote: >> Proposed text: >> RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) >> which is formally made historic by this document. Although as specified >> in [ARCH] IANA should limit the IPv6 Global Unicast address space to >> 2000::/3 for now, IANA might later delegate currently unassigned parts >> of the IPv6 address space to the purpose of Global Unicast as well. >> Implementations MUST NOT make address range checks for Global Unicast >> addresses. > Erik Nordmark > I'm missing the association with this document. The idea is that developers must not hardcode any assumptions. The reason they must not is because IANA will later delegate the currently unassigned parts of the space to a purpose we don't know, including possibly an extension to Global Unicast. > If we need to have a document which restates the instructions > to the IANA to allocate IPv6 addresses, can't we make that a > separate exercise? This is not the intent. Would you detail what makes you read the text that way? 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 24 11:38:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJcf7f006953; Mon, 24 Feb 2003 11:38:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OJcflp006952; Mon, 24 Feb 2003 11:38:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJcb7f006945 for ; Mon, 24 Feb 2003 11:38:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OJcjVK026747 for ; Mon, 24 Feb 2003 11:38:46 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04347 for ; Mon, 24 Feb 2003 11:38:38 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:36 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:36 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:36 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:34:35 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1OJYVJR005563; Mon, 24 Feb 2003 14:34:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05165; Mon, 24 Feb 2003 14:34:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030224140504.03f26948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 14:34:29 -0500 To: dhcwg@ietf.org, From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: References: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Thanks for your review and feedback on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02 My comments are in line... - Ralph At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: >On Tue, 11 Feb 2003, Ralph Droms wrote: > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > > options and a mechanism through which a "delegating router" (e.g., an ISP > > aggregation device) can assign and delegate one or more prefixes to a > > "requesting router" (e.g., CPE). This draft is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > >A few comments. > >Bigger issues -- I'm sorry for bringing them up so late (relatively), but >I haven't really thought/read about the big picture, before. > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be >mostly redundant -- the requesting router should just take the minimum of >lifetimes of the prefixes, calculate it in the same fashion, that's it. >Of course, there is an assumption (which doesn't seem to be properly >addressed!) that the requesting router is free to refresh the delegation >when it feels right, even every hour, day, month etc. without regard to >the lifetimes -- indeed, I think *NO* implementation would just wait until >the last minute to refresh them. > >Is there something I'm missing? The spec allows for flexibility in deployment scenarios by allowing the ISP (through the delegating router) to control the behavior of the requesting router, or by leaving the behavior under the control of the requesting router by setting T1 and T2 to 0 (see section 8 of the draft). >2) Multiple IA_PD looks unnecessarily complex. Are there any valid >reasons why it wouldn't be just enough to have only one IA_PD per >requesting router? (The option to and subsequent complexity of) >generating one for each interface seems like a completely unnecessary >feature to me -- it's the router which should be doing prefix delegation >to it's downstream interfaces! > >The only feature I can quickly think of which could profit from this is >kind of "shared routers" where the connected interfaces are separate >administrative entities with differently configured properties at the ISP. >This seems questionable to me, a case for manual configuration or >"advanced prefix delegation" to me. > >So, I think the possibility to do prefix delegation in more complex ways >than really necessary should be seriously considered. Keep it Simple, >Stupid would be a good rule. There is no requirement that the delegating router supply more than one IA_PD to the requesting router, and limiting the delegation to only one IA_PD seems overly restrictive. For example, a delegating router might send one IA_PD for each ISP used by a customer site. It is not the intention of the draft that the requesting router receive one IA_PD for each of its downstream interfaces. If that is your understanding of the draft, then we need to clarify the text. In section 11.1, the draft specifies that the requesting router assigns subnets from the delegated prefixes to each of its downstream interfaces. >3) One item that may also need some consideration is the option to let the >requesting router give its preference to some values (prefix length, >lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not >sure of the usefulness of these, really. In the real world, I think ISP's >set them, either to some values communicated off-band, or otherwise. The >complexity required (policy, policy,...) when the delegating router must >decide whether it can agree to the requested values seems like a big hit. >I'm not really sure whether it's worth it, even though it may offer some >flexibility for some corner cases. The only commonly used one I could >think of would be whether the customer wants _single_ /64 (for the only >one subnet!) or whole /48 -- seems like a heavy baggage for that. The cost of allowing the requesting router to express its preferences isn't all that great - a simple delegating router can simply ignore the requesting router's preferences... >4) As one who hasn't really read DHCPv6 specification, the spec was >confusing as it introduced options and code values, and reused ones from >DHCPv6 quite liberally (more of this below in detailed comments). I would >have hoped for a bit clearer picture of elements associated with DHCP >prefix delegation. Well, this option (and the spec) really isn't useful without DHCP, so I don't think it's unreasonable to expect a fair amount of familiarity with DHCPv6 on the part of the reader. However, we can edit the draft to include some additional definitions and concepts from DHCPv6 for clarity. >5) as above, there doesn't seem to be clear structure to the document when >specifying the DHCPv6 PD-specific options (and different DHCPv6 options >altogether) [sections 8-9, mostly]: this makes it rather difficult to >follow the which options include which options, what options may be >embedded in which, etc. This may partially be due to the fact I'm not so >familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was >missing. We can take a look at those sections and try to edit them for clarity, and we'll make some changes based on the more detailed comments you made below... >==> in consequence I think there are at least two items, 1-3 which need >some thought (if they haven't already been brought up and discussed), and >at least 4-5 which would clarify the specification which are IMO very >important in conveying the right message. > >As for more detailed comments...: > > Identity Association for Prefix Delegation (IA_PD) A collection of > prefixes assigned to the requesting router. Each > IA_PD has an associated IAID. > >==> first use of "IAID", so spell it out, or even put is as an item in the >terminology, as it keeps cropping up all the time. OK. >4. Model and Applicability > >==> the middle/latter part of this paragraph could be reorganized/reworded >a bit to say that the model described there is indeed just an example; >perhaps break off starting at page 5 as a separate sub-section? I suppose we could break section 4 into a couple of subsections, to clarify what text is describing the example scenario and what text is describing the use of the prefix delegation option more generally. >The delegating router chooses prefix(es) > for delegation, and returns the prefix(es) to the requesting router. > >==> the use of "returns the prefix(es)" seems slightly ambiguous -- could >one read that and get a picture that the delegator gives back the same >prefixes requested? Did I misunderstand, or did you mean along the lines >of "responds with prefixes delegated to the requesing router" ? "responds with prefixes[...]" is the correct clarification; we can make that change. > Figure 1 illustrates a network architecture in which prefix > delegation would be used. > >==> s/would/could/ ? OK. > The IAID uniquely identifies the IA_PD and must be chosen to be > unique among the IA_PD IDs on the requesting router. > >==> s/IDs/IAIDs/ ? Yes. > option-code: OPTION_IA_PD (TBD) > > option-length: 12 + length of IA_PD-options field. > >==> is it necessary to say how the option-code is stored/transported >(signed/unsigned) ? I guess this is clear enough? The format of the option code is (should be?) specified in the DHCPv6 spec. >==> length of IA_PD-options field in which units? Octets, seems likely? OK. >==> same issues in sect 9 > > T1 The time at which the requesting router contacts > T2 The time at which the requesting router contacts > >==> s/contacts/should contact/ or even "is instructed to contact" OK > IA_PD-options Options associated with this IA_PD. > > The IA_PD-options field encapsulates those options that are specific > to this IA_PD. For example, all of the IA_PD Prefix Options carrying > the prefixes associated with this IA_PD are in the IA_PD-options > field. > >==> one should refer to the next section and explain that currently, only >IA_PD Prefix option is defined? (I'd structure section 9 maybe >differently: like "IA_PD options" as the main section title, and the >current one as a subsection, but some other clarification would also be >ok). OK. > In a message sent > by a delegating router to a requesting router, the requesting router > MUST use the values in the T1 and T2 fields for the T1 and T2 > parameters. > >==> the first part of the sentence is awkward, did you mean something like >"In case the message sent by the delegating router included non-zero T1 or >T2, the parameters MUST be used" ? OK. > The status of any operations involving this IA_PD Prefix option is > indicated in a Status Code option in the IAprefix-options field. > >==> Status Code options haven't been explained. We can add an entry in the terminology section with a pointer to the DHCPv6 spec. > The requesting router MUST ignore any Advertise message that includes > a Status Code option containing the value NoPrefixAvail, > >==> where is the defintion of NoPrefixAvail or other codes? Needs a pointer to the DHCPv6 spec? > message for the user, a Server Identifier option with the delegating > router's DUID and a Client Identifier option with the requesting > router's DUID. > >==> DUID used for the first time (inherited from DHCPv6 spec I think), >spell it out? Needs a pointer to the DHCPv6 spec? >==> all in all, I think one should have a better picture which kinds of >options from DHCPv6 spec which aren't mentioned in the draft are ok (or if >some aren't applicable) -- or at least refer to those in the previous >sections. > > Each prefix has valid and preferred lifetimes whose duration is > >==> s/duration is/durations are/ OK. > When a requesting router subnets a delegated prefix, it must assign > additional bits to the prefix to generate unique, longer prefixes. > For example, if the requesting router in Figure 1 were delegated > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber > network. > >==> I'm not sure if the first sentence is entirely accurate. One could >use prefix delegation to get multiple /64's directly from your ISP, then >extra bits wouldn't be needed at all. But that wouldn't be "subnetting", I don't think - just reassignment? > When a delegating router receives a Request message from a requesting > router that contains an IA_PD option, and the delegating router is > authorised to delegate prefix(es) to the requesting router, the > delegating router selects the prefix(es) to be delegated to the > requesting router. The mechanism through which the delegating router > selects prefix(es) for delegation is not specified in this document. > Section 10.2 gives examples of ways in which a delegating router > might select the prefix(es) to be delegated to a requesting router. > > A delegating router examines the prefix(es) identified in IA_PD > Prefix options (in an IA_PD option) in Renew and Rebind messages and > responds according to the current status of the prefix(es). [...] > >==> These paragraph deal with a different message types and situations, >etc., so separating them more clearly in the text would be useful (start >using a similar sentence or whatever) > >==> same goes in the next paragraph OK. >14. Security Considerations > >==> personally I'm rather worried about the requestor being able to give >"guidance" to the delegator what on what it wants. Unreliable input could >lead to bad results in an implementation which hasn't been done carefully >(requesting link/site-local prefixes which don't exist, effect of bogus >prefixlengths etc.etc.). [more of this was above] Paranoid delegating routers can simply ignore the guidance... >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 11:38:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJcr7f006970; Mon, 24 Feb 2003 11:38:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OJcrmA006969; Mon, 24 Feb 2003 11:38:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OJcj7f006959 for ; Mon, 24 Feb 2003 11:38:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OJcrVK026814 for ; Mon, 24 Feb 2003 11:38:54 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28449 for ; Mon, 24 Feb 2003 12:38:47 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:35:12 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:33:33 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:35:11 Z Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 19:35:11 Z 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 h1OJZ7d15014; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1OJZ7Z11540; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Feb 2003 13:35:07 -0600 Message-Id: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 24 Feb 2003 13:33:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC3B.9AC3CE60" 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_01C2DC3B.9AC3CE60 Content-Type: text/plain; charset="iso-8859-1" Isn't it possible for the DHCPv6 server to return IPv4 addresses as per RFC 2373, section 2.5.4 (IPv6 Addresses with Embedded IPv4 Addresses), in particular: A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 24, 2003 12:43 PM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DC3B.9AC3CE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: WG last call on = draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Isn't it possible for the DHCPv6 server to return = IPv4 addresses as per
RFC 2373, section 2.5.4 (IPv6 Addresses with = Embedded IPv4 Addresses),
in particular:

   A second type of IPv6 address which = holds an embedded IPv4 address is
   also defined.  This address is = used to represent the addresses of
   IPv4-only nodes (those that *do not* = support IPv6) as IPv6 addresses.
   This type of address is termed an = "IPv4-mapped IPv6 address" and has
   the format:

   = |            = ;    80 = bits           &n= bsp;   | 16 |      32 = bits        |
   = +--------------------------------------+--------------------------+
   = |0000..............................0000|FFFF|    IPv4 = address     |
   = +--------------------------------------+----+---------------------+

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 24, 2003 12:43 PM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; = namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Summary of discussion during WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Pekka Savola, Tony Lindstrom, Bernie Volz and Peter = Koch all responded with
editorial suggestions.  These suggestions have = been incorporated into the
draft and will appear in next published rev.

Peter Koch and Rob Austein commented on the = "Security Considerations";
specifically, whether DNSSEC can prevent problems = caused by a search list
supplied as part of an attack by a DHCP = server.  Based on Rob's argument
(and assuming I understood Rob correctly) that = DNSSEC can guarantee that a
host can trust the replies it receives, but DNSSEC = can't guarantee that the
host has asked the right question based on its = search list, I'm inclined to
leave the text in question unchanged.

Alain Durand raised the issue of supplying both IPv4 = and IPv6 addresses for
DNS resolvers in the DNS server option.  I = judged the rough consensus in
the responses to be that restricting the DNS server = option to return only
IPv6 addresses is acceptable.

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DC3B.9AC3CE60-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 12:50:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OKo67f008309; Mon, 24 Feb 2003 12:50:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OKo5IR008308; Mon, 24 Feb 2003 12:50:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OKo27f008301 for ; Mon, 24 Feb 2003 12:50:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OKoAVK025540 for ; Mon, 24 Feb 2003 12:50:10 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25264 for ; Mon, 24 Feb 2003 12:50:05 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 20:50:04 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 20:50:04 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 20:50:03 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 20:50:03 Z 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 MAA15871; Mon, 24 Feb 2003 12:50:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1OKnwu04711; Mon, 24 Feb 2003 12:49:58 -0800 X-mProtect: <200302242049> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn2CHki; Mon, 24 Feb 2003 09:57:19 PST Message-Id: <3E5A5E0E.8000108@iprg.nokia.com> Date: Mon, 24 Feb 2003 10:01:50 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt References: <200302211825.h1LIP18R013627@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas et al, The main message I am getting is that the "L" bit is a don't-care from the standpoint of RFC 2462 section 5.5, and I agree that that point needs no further clarification. But, I'm still a bit uncertain on the following point: Thomas Narten wrote: > This question applies to any address a node autoconfigures, regardless > of the setting of the L-bit. The scope of the advertisement of course > applies to the interface on which it receives. When you say that the scope of the advertisement applies to the interface on which it receives, are you also implying that the scope of any addresses autoconfigured from prefixes received in the advertisement apply to the interface as well - regardless of the state of the "L" bit? Asked another way, when a prefix option has the "A" bit set and the "L" bit NOT set, should the address autoconfigured from the prefix be: a) assigned to the receiving interface, b) treated as a node_ID independent of any of the node's interfaces, or c) implementor's-choice? Thanks, Fred Templin ftemplin@iprg.nokia.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 Mon Feb 24 13:49:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OLnt7f009057; Mon, 24 Feb 2003 13:49:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1OLntH4009056; Mon, 24 Feb 2003 13:49:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1OLnq7f009049 for ; Mon, 24 Feb 2003 13:49:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1OLo0VK015916 for ; Mon, 24 Feb 2003 13:50:00 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06274 for ; Mon, 24 Feb 2003 14:49:54 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 21:47:10 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 21:45:40 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 21:45:40 Z Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Feb 2003 21:45:40 Z Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1OLjI4e081614; Mon, 24 Feb 2003 16:45:18 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1OLjHEJ033898; Mon, 24 Feb 2003 14:45:17 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h1OLeiem028044; Mon, 24 Feb 2003 16:40:45 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h1OLeiLX028037; Mon, 24 Feb 2003 16:40:44 -0500 Message-Id: <200302242140.h1OLeiLX028037@rotala.raleigh.ibm.com> To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt In-Reply-To: Message from ftemplin@iprg.nokia.com of "Mon, 24 Feb 2003 10:01:50 PST." <3E5A5E0E.8000108@iprg.nokia.com> Date: Mon, 24 Feb 2003 16:40:43 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Fred. > The main message I am getting is that the "L" bit is a don't-care from > the standpoint of RFC 2462 section 5.5, and I agree that that point needs no > further clarification. But, I'm still a bit uncertain on the following point: > Thomas Narten wrote: > > This question applies to any address a node autoconfigures, regardless > > of the setting of the L-bit. The scope of the advertisement of course > > applies to the interface on which it receives. > When you say that the scope of the advertisement applies to the interface > on which it receives, are you also implying that the scope of any addresses > autoconfigured from prefixes received in the advertisement apply to the > interface as well - regardless of the state of the "L" bit? Yes. > Asked another > way, when a prefix option has the "A" bit set and the "L" bit NOT set, > should the address autoconfigured from the prefix be: a) assigned to the > receiving interface, Yes > b) treated as a node_ID independent of any of the node's interfaces, No. > c) implementor's-choice? No. What wording would lead you to think to answer yes to b) or c)? I'm also puzzled that you would think that doing b) would make sense. In most cases, it would not. The different interfaces will likely connect to different links that have different subnet prefixes assigned to them. It wouldn't make sense to assign an address on an interface that the routers (or hosts) on that link wouldn't know were on that link. 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 Mon Feb 24 16:04:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P0437f010459; Mon, 24 Feb 2003 16:04:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P043vN010458; Mon, 24 Feb 2003 16:04:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P0407f010451 for ; Mon, 24 Feb 2003 16:04:00 -0800 (PST) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1P048il393565 for ; Mon, 24 Feb 2003 16:04:08 -0800 (PST) Date: Mon, 24 Feb 2003 16:04:08 -0800 From: Michael Hunter To: ipng@sunroof.eng.sun.com Subject: ADMIN: Too many hops... Message-Id: <20030224160408.0200aaef.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sun recently implemented new anti-spam measures which increase the number of hops email takes into sunroof (and thus the whole path from poster to mailing list). This weekend I saw two thousand messages to the ipng admin mailbox of which ~80% represent bounces due to too many hops. According to the local sendmail expert the sendmail default of 25 hops is low and the returns I'm seeing from some sites of max hops being under 20 is nuts. I'm asking that all of you talk to your admins about getting this parameter bumped up on your mail gateways. I'll be contacting specific sites but external suggestions on issues like this rarely result in changes as quick as internal pressure. Michael Hunter ipng admin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 17:15:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P1FH7f010813; Mon, 24 Feb 2003 17:15:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P1FH1e010812; Mon, 24 Feb 2003 17:15:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P1FC7f010802 for ; Mon, 24 Feb 2003 17:15:12 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1P1FJim409690; Mon, 24 Feb 2003 17:15:19 -0800 (PST) Message-Id: <200302250115.h1P1FJim409690@jurassic.eng.sun.com> Date: Mon, 24 Feb 2003 17:15:32 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Draft on IPv6 source address selection socket API To: ipng@sunroof.eng.sun.com Cc: erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Crash_of_Rhinoceros_837_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Crash_of_Rhinoceros_837_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6gCiW1aVCVzOFtagwzFmFA== We have had discussion about requirement of having a socket-API on source address selection, in this alias. A draft has been submitted to address source address selection at the per-socket (and per apps) basis. Currently it discusses preferences of source address selection by the application for privacy addresses, mobileipv6 addresses and Cryptographically generated addresses. Thus the application can reverse the sense of default source address selection by using the proposed APIs. Please provide your comments/feedback on the alias and to the authors. We have listed some open issues in the draft as well to seek suggestions from the working group for further enhancement of the draft. The draft will be available in the draft directory shortly, however, I am including the text file here. Thanks, -Samita --Crash_of_Rhinoceros_837_000 Content-Type: TEXT/plain; name="draft-chakrabarti-ipv6-addrselect-api-00.txt"; charset=us-ascii Content-Description: draft-chakrabarti-ipv6-addrselect-api-00.txt Content-MD5: sohQfoqa30epH6vfyjz5KA== INTERNET-DRAFT Erik Nordmark Expires: August, 2003 Samita Chakrabarti Sun Microsystems, Inc. Julien Laganier Sun Microsystems, Inc. LIP / ENS-Lyon February, 2003 IPv6 Socket API for source address selection Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires August, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 1] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 Abstract The IPv6 default address selection document describes the rules for selecting default source address by the system and indicates that the applications should be able to reverse the sense of system preference of source address selection for that application through possible API extensions. However, no such socket APIs exist in the basic or advanced IPv6 socket API documents. Hence this document specifies socket level options to prefer a particular source address as per the choice of the applications. It also discusses implications on the name-to-address translation API that performs part of the default address selection. The socket APIs described in this document will be particularly useful for Mobile IPv6 enabled applications and other IPv6 applications which want to choose between temporary and public addresses, CGA (cryptographically generated addresses) and non-CGA addresses etc.. Table of Contents 1. Introduction ........................................... 3 2. Example Usage .......................................... 4 3. Changes to the Socket Interface ........................ 5 4. Changes to the protocol-independent nodename translation ............................ 6 5. IPv4-Mapped IPv6 Addresses .............................. 7 6. Security Considerations ................................. 7 7. Open Issues ............................................. 7 8. References .............................................. 8 9. Acknowledgements ........................................ 8 10. Authors' Addresses ...................................... 9 draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 2] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 1. Introduction This document defines socket extensions to support the non-default choice of source address by the applications. The IPv6 default address selection [1] document has specified the rules for system default source address selection for an outbound IPv6 packet. Privacy considerations [6] have introduced "public" and "temporary" addresses. IPv6 Mobility [3] introduces "home address" and "care- of-address" definitions in the mobile systems. Although it is desirable to have default algorithms for the system to choose the source address of the outgoing IPv6 packet, an application may want to reverse that rule for efficiency and other application specific reasons. Currently IPv6 socket API extensions does not provide a mechanism to choose a particular source address other than simple bind() operation. The bind() operation allows an application to specify a particular source address. Thus in order to use bind() the application itself must make sure that the source address is appropriate for the destination address (e.g., with respect to the interface used to send packets to the destination). The application also needs to make sure about the appropriate scope of source address with respect to the destination address and so on. The mechanism presented in this document allows the application to specify attributes of the source addresses it prefers while still having the system do the rest of the default address selection. A socket option has been deemed useful for this purpose, as it enables an application ability to make a choice of source address at per-socket basis as well as it can provide flexibility of enabling and disabling choice of source addresses in non-connected sockets. The socket option uses a set of flags for source address preferences. Since source address selection and destination address ordering need to be partially implemented in getaddrinfo() [2] the corresponding set of flags are also defined for that routine. Thus this document introduces different flags for source address selection that can be used by the applications for Mobility [3], Privacy Extension [6] and CGA [7] scenarios. In future, more flags can be added to designate a choice for a certain type of source address as the needs may arise. The approach in this document is to allow the application to specify preferences on source addresses and not to be able to specify hard requirements. Thus for instance an application can specify that it prefers temporary addresses but if no temporary addresses are available to the default address selection algorithm, a public address would be chosen instead. draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 3] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 Furthermore, the approach is to define two flags for each purpose, so that an application can specify either that it prefers 'X' or prefers 'not X', or it can choose not to set either of the flags relating to 'X' and leave it up to the system default, perhaps while specifing its preferences for some other attribute of the source addresses. 2. Example Usages The examples of usages discussed here are limited to applications supporting Mobile IPv6, IPv6 Privacy Extensions and Cryptographically Generated Addresses. Address selection document [1] recommends that home addresses should be preferred over care-of-address when both are configured. However, a mobile node may want to prefer care-of-address as source address for DNS query in the foreign network as it normally means a shorter and local return path compared to the route via the mobile node's home-agent when the query contains home-address as source address. Another example is IKE application which requires care-of-address as its source address for the initial security association pair with Home Agent [3] while the mobile node boots up at the foreign network and wants to do the key exchange before a successful home-registration. Also a Mobile IPv6 aware application may want to toggle between home-address and care-of-address depending on its location and state of the application. It may also want to open different sockets and use home-address as source address for one socket and care-of-address for the others. In a non-mobile environment, similarly an application may prefer to use temporary address as source address for certain cases. By default, the source address selction rule selects "public" address when both are available. For example, an application supporting web browser and mail-server may want to use "temporary" address for the former and "public" address for the mail-server as a mail-server may require reverse path for DNS records for anti-spam rules. Similarly, a node may be configured to use the cryptographically genenerated addresses by default, but an application may prefer not to use it. For instance, fping, a debugging tool which tests basic reachability of multiple destinations by sending packets in parallel, may find that the cost and time incurred in proof-of- ownership by CGA verification is not justified. On the other hand, when a node is not configured for CGA as default, an application may prefer using CGA by setting the socket option. It may subsequently verify that it is truly bound to a CGA by first calling getsockname() and then recomputing the CGA using the public key of the node. draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 4] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 3. Changes to the Socket Interface IPv6 Basic API [2] defines socket options for IPv6. This document adds a new socket option at the IPPROTO_IPV6 level. This socket option is called IPV6_SRC_PREFERENCES. It can be used with setsockopt() and getsockopt() calls. This socket option takes a 32bit unsigned integer argument. The argument consists of a number of flags which indicate the choice of source address selection. The flags defined in this document are: IPV6_PREFER_SRC_HOME IPV6_PREFER_SRC_COA IPV6_PREFER_SRC_TMP IPV6_PREFER_SRC_PUBLIC IPV6_PREFER_SRC_CGA IPV6_PREFER_SRC_NONCGA The following example illustrates how it is used: uint32_t flags = IPV6_PREFER_SRC_COA; if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES, (char *) &flags, sizeof (flags)) == -1) { perror("setsockopt IPV6_SRC_REFERENCES"); } When the IPV6_SRC_PREFERENCES is successfully set with setsockopt(), the option value given is used to specify source address for any connection initiation through the socket and all subsequent packets sent via that socket. If the option is not set, the system selects a default value. Setting conflicting flags at the same time results in the error EINVAL. It is recommended that the application does a getsockopt() prior calling to setsockopt() call so that it can save the existing source address preference value, in the cases when the application might need to restore the preferences. The constants mentioned in this section are defined in . draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 5] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 4. Changes to the protocol-independent nodename translation Section 8 of Default Address Selction [1] document indicates about possible implementation strategy for getaddrinfo() [2]. getaddrinfo() collects available source addresses from the network layer and then it sorts the list of source addresses as per source address selection rules. Thus if an application sets setsockopt() IPV6_SRC_PREFERENCES option to alter the default address selection rules , it must make sure that it calls getaddrinfo() with the corresponding flags specified in this section. This will ensure correct behavior of getaddrinfo() destination address selection based on the sorted list of source addresses as per the socket source address selection preferences. The following flags are added for the ai_flags in addrinfo data structure defined in Basic IPv6 Socket API Extension [2]. AI_PREFER_SRC_HOME AI_PREFER_SRC_COA AI_PREFER_SRC_TMP AI_PREFER_SRC_PUBLIC AI_PREFER_SRC_CGA AI_PREFER_SRC_NONCGA The above flags are ignored for the AF_INET address family. If a returned address is an IPv4 address (either as AF_INET6 when AI_V4MAPPED, or as AF_INET) then the source preference flags have no effect. If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_ COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS[2]. Some valid sequences of flags would be: AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC AI_PREFER_SRC_COA | AI_PREFER_SRC_PUBLIC AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA AI_PREFER_SRC_COA | AI_PREFER_SRC_CGA AI_PREFER_SRC_COA | AI_PREFER_SRC_NONCGA All the constants mentioned in this section for ai_flags are defined in . draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 6] INTERNET DRAFT IPv6 Socket API for source address selection Feb., 2003 5. IPv4-Mapped IPv6 Addresses IPv4-Mapped IPv6 addresses are not supported for setting preference on home, care-of-address, CGA, non-CGA, public or privacy auto- configured addresses as source addresses. Because they are all pure IPv6 addresses. 6. Security Considerations This document conforms to the same security implications as specified in IPv6 Basic Socket API [2] document. It is also recommended that the applications set IPV6_V6ONLY IP level socket option to permit the nodes to not process IPv4 packets as IPv4 Mapped addresses. Allowing applications to specify a preference for temporary addresses provides per-application (and per-socket) ability to use the privacy benefits of the temporary addresses. 7. Open Issues - Are there more flags we should define at this point in time? For instance, PREFER_LARGEST_SCOPE? - Is there a need for REQUIRE flags in addition to or instead of the PREFER flags? Note that in general it isn't possible to verify that a requirement can be satisfied until sendto() or connect() (when the destination address is known) thus this would result in late errors being reported to the application. - Is there a need for "validation" functions to go with these preferences such as functions that check whether an address is a temporary address? draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 7] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 8. References Normative references: [1] Richard Draves, "Default Address Selection for IPv6", draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002. [2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens, "Basic Socket Interface Extensions for IPv6", draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002. Informative references: [3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-20.txt, January, 2003. [4] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, Dec. 1998. [5] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt April 19, 2002. [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [7] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [8] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", draft-irtf-gsec-sgmv6-01 (work in progress), July 2002. 9. Acknowledgements The authors like to thank members of mobile-ip and ipv6 working groups for useful discussion on this topic. Richard Draves and Dave Thaler suggested that getaddrinfo also needs to be considered along with the new socket option. Gabriel Montenegro suggested that CGAs may also be considered in this document. Thanks to Alain Durand, Renee Danson, Alper Yegin and Francis Dupont for useful discussions. draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 8] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 10. Authors' Addresses Erik Nordmark Sun Microsystems Laboratories, Europe 180 Avenue de l'Europe 38334 Saint Ismier, France Email: Erik.Nordmark@sun.com Samita Chakrabarti Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054, USA Email: samita.chakrabarti@Sun.com Julien Laganier Sun Microsystems Laboratories, Europe 180 Avenue de l'Europe 38334 Saint Ismier, France Email: Julien.Laganier@Sun.COM draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 9] --Crash_of_Rhinoceros_837_000-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 17:27:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P1RN7f011498; Mon, 24 Feb 2003 17:27:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P1RMZk011497; Mon, 24 Feb 2003 17:27:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P1RI7f011489 for ; Mon, 24 Feb 2003 17:27:19 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h1P1RQim412285; Mon, 24 Feb 2003 17:27:26 -0800 (PST) Message-Id: <200302250127.h1P1RQim412285@jurassic.eng.sun.com> Date: Mon, 24 Feb 2003 17:27:39 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: IPv6 advanced socket API extension for MIPv6 To: ipng@sunroof.eng.sun.com Cc: Erik.Nordmark@Sun.COM, Samita.Chakrabarti@eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Drift_of_Hogs_283_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Drift_of_Hogs_283_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Yu5qeialcZ2FkSumMJOQcQ== FYI. A draft has been submitted in the 'mobileip' wg to discuss extension of IPv6 socket APIs for MIPv6. The draft includes mechanism : * to observe MH(Mobility Header) packets at the user level * to access HOA and Routing header type 2 at the user level * Defines MH protocol in /etc/protocols * Defines basic MIPv6 data structure for portability of apps. Please provide comments in the mobileip wg alias and to the authors. Thanks, -Samita --Drift_of_Hogs_283_000 Content-Type: TEXT/plain; name="draft-chakrabarti-mobileip-mipext-advapi-00.txt"; charset=us-ascii Content-Description: draft-chakrabarti-mobileip-mipext-advapi-00.txt Content-MD5: R2xx48OSo55PaI9ZnH9xHg== INTERNET-DRAFT Samita Chakrabarti Expires: August, 2003 Erik Nordmark Sun Microsystems, Inc. February, 2003 Extension to Sockets API for Mobile IPv6 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires August, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 1] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home address destination option and Routing header type 2 extension headers. It also discusses the common data structures and defines that might be used by the advanced Mobile IPv6 socket applications. Table of Contents 1. Introduction ........................................... 3 2. Common Structures and Definitions ...................... 4 2.1 The Mobility Header Data Structures ................ 5 2.2 Mobility Header Constants .......................... 7 2.3 IPv6 Home Address Destination Option ................ 8 2.4 Routing Header Type 2 ................................8 3. Access to Home Address Destination Option and Routing Headers ................................ 9 3.1 Routing Header Access Functions ..................... 10 3.2 Home Address Destination Option Access Functions .....10 4. Mobility Protocol Headers ............................... 11 4.1 Receiving and Sending Mobility Header Messages ..... 11 5. Protocols File ............................................12 6. IPv4-Mapped IPv6 Addresses ................................12 7. Security Considerations ...................................12 8. References ................................................13 9. Authors' Addresses .................................... ..13 draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 2] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 1. Introduction Mobility Support in IPv6 [2] defines a new mobility protocol header, home address destination option and a new routing header type. It is expected that Mobile IPv6 user level implementations and some applications will need to access and process these IPv6 extension headers. This document is an extension to existing Advanced Sockets API document [1]; it addresses the IPv6 Sockets API for Mobile IPv6 protocol support. The target applications for this socket APIs are believed to be the debugging and diagnostic applications as well as some policy applications which would like to receive a copy of protocol information at the application layer. This document can be divided into the following parts. 1. Definitions of constants and structures for C programs that capture the Mobile IPv6 packet formats on the wire. A common definition of these is useful at least for packet snooping appplications. This is captured in section 2. 2. Notes on how to use the IPv6 Advanced API to access home address options and routing headers of type 2. This is captured in section 3. 3. Notes on how user-level applications can observe MH (Mobility Header) packets using raw sockets (in section 4). The IPv6 RAW socket interface described in this document, allows applications to receive MH packets whether or not the systems MH processing takes place in the "kernel" or at the "user space". 4. Suggested name for /etc/protocols (in section 5). It is anticipated that Mobile IPv6 will be used widely from mobile devices to Server and Routing platforms. Thus it is useful to have a standard API for portability of Mobile IPv6 applications on a wide variety of platforms and operating systems. draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 3] INTERNET-DRAFT Extensions to Sockets API for MIPv6 February, 2003 The packet information along with access to the extension headers (Routing header and Destination options) are specified using the "ancillary data" fields that were added to the 4.3BSD Reno sockets API in 1990. The reason is that these ancillary data fields are part of the Posix.1g standard and should therefore be adopted by most vendors. This is in conformance with Advanced API for IPv6 sockets [1]. This document does not address application access to either the authentication header or the encapsulating security payload header. All examples in this document omit error checking in the favor of brevity. We note that many of the functions and socket options defined in this document may have error returns that are not defined in this document. Many of these possible error returns will be recognized only as implementations proceed. Datatypes in this document follow the Posix.1g format: intN_t means a signed integer of exactly N bits (e.g., int16_t) and uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t). This document provides guidelines on MIPv6 socket applications and believes that some other appropriate standardization body will standardize the APIs along with other IPv6 advanced socket APIs. 2. Common Structures and Definitions This API assumes that the fields in the protocol headers are left in the network byte order, which is big-endian for the Internet protocols. If not, then either these constants or the fields being tested must be converted at run-time, using something like htons() or htonl(). A new header file : draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 4] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 2.1. The Mobility Header Data Structures 2.1.1 The mh_hdr Structure The following structure is defined as a result of including . This is fixed part of the mobility header. struct mh_hdr { uint8_t mh_proto; /* NO_NXTHDR by default */ uint8_t mh_hdrlen; /* Header Len in unit of 8 Octets */ uint8_t mh_type; /* Type of Mobility Header */ uint8_t mh_resvd; /* Reserved */ uint16_t mh_cksum; /* Mobility Header Checksum */ /* Followed by BU/BR/BA/BM/HOT[I]/COT[I] specific parts */ }; 2.1.2 Binding Update Mobility Message struct mh_binding_update { struct mh_hdr mh_bu_hdr; uint16_t mh_bu_seqno; /* Sequence Number */ uint16_t mh_bu_flags_ack : 1, /* Request a binding ack */ mh_bu_flags_home : 1, /* Home Registration */ mh_bu_flags_ll : 1, /* Link Local address capability */ mh_bu_flags_sa : 1, /* Key management capability */ mh_bu_flags_resvd : 12; /* Reserved */ uint16_t mh_bu_lifetime; /* Time in unit of 4 sec */ /* Followed by optional Mobility Options */ }; 2.1.3 Binding Acknowledgment Mobility Message struct mh_binding_ack { struct mh_hdr mh_ba_hdr; uint8_t mh_ba_status; /* Status code */ uint8_t mh_ba_flags_sa : 1, /* IPSec Key managemnt flag */ mh_ba_flags_resvd : 7; /* Reserved */ uint16_t mh_ba_seqno; uint16_t mh_ba_lifetime; /* Followed by optional Mobility Options */ }; draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 5] INTERNET DRAFT Extension to Sockets API for MIPv6 February, 2003 2.1.4 Binding Request Mobility Message struct mh_binding_request { struct mh_hdr mh_br_hdr; uint16_t mh_br_resvd; /* Followed by optional Mobility Options */ }; 2.1.5 Binding Error Mobility Message struct mh_binding_error { struct mh_hdr mh_be_hdr; uint8_t mh_be_status; /* Error Status */ uint8_t mh_be_resvd; struct in6_addr mh_be_homeaddr; /* Followed by optional Mobility Options */ }; 2.1.6 Common Data structure used by HOTI/COTI messages HOTI/COTI messages are defined in IPv6 Mobility Support [2] document. These messages are sent by Mobile node in order to initiate Return Routability Procedure in Route Optimization protocol. struct mh_hoti_coti { struct mh_hdr mh_hc_hdr; uint16_t mh_hc_resvd; uint32_t mh_hc_cookie[2]; /* 64 bit Cookie by MN */ /* Followed by optional Mobility Options */ }; 2.1.7 Home Address Test (HOT) Message struct mh_hot { struct mh_hdr mh_hot_hdr; uint16_t mh_hot_nonceId; uint32_t mh_hot_cookie[2]; /* Cookie from HOTI msg */ uint32_t mh_hot_hm_keygen[2]; /* 64 Bit Key by CN */ /* Followed by optional Mobility Options */ }; draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 6] INTERNET DRAFT Extension to Sockets API for MIPv6 February, 2003 2.1.8 Care Of Address Test (COT) Message struct mh_cot { struct mh_hdr mh_cot_hdr; uint16_t mh_cot_nonceId; uint32_t mh_cot_cookie[2]; /* Cookie from COTI message */ uint32_t mh_cot_coa_keygen[2]; /* 64bit key by CN */ /* Followed by optional Mobility Options */ }; 2.1.9 Mobility Option TLV data structure struct mh_mobility_opt { uint8_t mh_mopt_type; /* Option Type */ uint8_t mh_mopt_len; /* Option Length */ /* Variable Option Data in bytes */ }; 2.1.10 Mobility Option Data Structures TBD 2.2 Mobility Header Constants IPv6 Next Header Value for Mobility: #define IPPROTO_MH 62 /* IPv6 Mobility Header: IANA-TBD */ Mobility Header Message Types: #define MH_TYPE_BRR 0 /* Binding Request */ #define MH_TYPE_HOTI 1 /* HOTI Message */ #define MH_TYPE_COTI 2 /* COTI Message */ #define MH_TYPE_HOT 3 /* HOT Message */ #define MH_TYPE_COT 4 /* COT Message */ #define MH_TYPE_BU 5 /* Binding Update */ #define MH_TYPE_BACK 6 /* Binding ACK */ #define MH_TYPE_BERROR 7 /* Binding Error */ draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 7] INTERNET DRAFT Extension to Sockets API for MIPv6 February, 2003 Mobility Header Message Option Types: #define MHOPT_PAD1 0x00 /* PAD1 */ #define MHOPT_PDAN 0x01 /* PADN */ #define MHOPT_UID 0x02 /* Unique ID */ #define MHOPT_ALTCOA 0x03 /* Alternate COA */ #define MHOPT_NONCEID 0x04 /* Nonce Index */ #define MHOPT_BAUTH 0x05 /* Binding Auth Data */ #define MHOPT_BREFRESH 0x06 /* Binding Refresh */ Status values accompanied with Mobility Binding Acknowledgement: #define MH_BAS_ACCPETED 0 /* Binding update accepted */ #define MH_BAS_UNSPECIFIED 128 /* Reason unspecified */ #define MH_BAS_ADMIN 129 /* Administratively prohibited */ #define MH_BAS_INSUFFICIENT 130 /* Insufficient resources */ #define MH_BAS_NOT_HA 131 /* HA registration not supported */ #define MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */ #define MH_BAS_WRONG_HA 133 /* Not HA for this mobile node */ #define MH_BAS_DAD_FAILED 134 /* DAD failed */ #define MH_BAS_SEQNO_BAD 135 /* Sequence number out of range */ #define MH_BAS_EXP_HOME_NI 136 /* Expired Home nonce index */ #define MH_BAS_EXP_COA_NI 137 /* Expired Care-of nonce index */ #define MH_BAS_EXP_NI 138 /* Expired Nonce Indices */ draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 8] INTERNET DRAFT Extension to Sockets API for MIPv6 February, 2003 2.3. IPv6 Home Address Destination Option /* Home Address Destination Option */ struct ip6_opt_hoa { uint8_t ip6hoa_type; uint8_t ip6hoa_len; uint8_t ip6hoa_addr[16]; } Option Type Definition: #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ 2.4 Routing Header Type 2 /* Type 2 Routing header for Mobility Protocol */ struct ip6_rthdr2 { uint8_t ip6r2_nxt; /* next header */ uint8_t ip6r2_len; /* length : always 2 */ uint8_t ip6r2_type; /* always 2 */ uint8_t ip6r2_segleft; /* segments left: always 1 */ uint32_t ip6r2_reserved; /* reserved field */ struct in6_addr ip6r2_homeaddr; /* Home Address */ }; draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 9] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 3. Access to Home Address Destination Option and Routing Headers Applications that need to be able to access home address destination option and routing header type 2 information should use the same mechanism defined in Advanced Sockets API for IPv6 in section 4. In order to receive Home Address destination option or route header type 2 extension header, application must call setsockopt() to turn on the corresponding flag: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); When any of these options are enabled, the corresponding data is returned as control information by recvmsg(), as one or more ancillary data objects. Receiving the above information for TCP applications is not defined in this document (see section 4.1 of Advanced Sockets API for IPv6[1]. For sending home address destination option, ancillary data can be used to specify the option content for a single datagram. This only applies to datagram and raw sockets; not to TCP sockets. For TCP data packets with home-address destination option may be used with "sticky" option for all transmitted packets. However, at this point, it is unknown why an application would want to set home-address option along with its data packets as Mobile IPv6 protocol takes care of it transparently at the protocol stack. Similarly it is not clear that if an application would need to set Router Header Type 2 extension to send data packets as it is taken care by the Mobile IPv6 protocol depending on the binding cache information. Thus this document does not specifically discuss the sending of Route Header Type 2 extension header. However, the following socket option parameters and cmsghdr fields may be used for sending the Home Address destination options. opt level/ optname/ optval/ cmsg_level cmsg_type cmsg_data[] ------------ ------------ ------------------------ IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure Some IPv6 implementations may support "sticky" options [1] for IPv6 destination option for datagram sockets. draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 10] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 3.1 Routing Header access functions While accessing Routing header Type 2 extension header, one MUST use type = 2 and segment = 1. The following functions are supported for Mobile IPv6 applications for sending and receiving Routing Header Type 2 headers: size_t inet6_rth_space(int type, int segments); void *inet6_rth_init(void *bp, int bp_len, int type, int segments); int inet6_rth_add(void *bp, const struct in6_addr *addr); int inet6_rth_segments(const void *bp); struct in6_addr *inet6_rth_getaddr(const void *bp, int index); NOTE: Reversing operation is not possible using Route Header Type 2 extension header. Detail description and examples of accessing a IPv6 Route Header are discussed in Advanced API for IPv6 Sockets [1]. 3.2 Home Address Destination Option access functions The application must enable the IPV6_RECVDSTOPTS socket option in order to receive the home address destination option: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); Each Destination option header is returned as one ancillary data object described by a cmsghdr structure with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_value() functions as defined in Advanced API for IPv6 sockets [1]. This document assumes that MobileIPv6 applications will not be allowed to send Home Address Destination Option from the application level, as Mobile IPv6 kernel takes care of sending home-address option and routing header type 2. However, the order of extension headers in conjunction with Home Address option sending is specified in Mobility Support in IPv6 [2] in section 6.3. The Destination options are normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10 of IPv6 Advanced API sockets [1]. draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 11] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 4. Mobility Protocol Headers Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility control messages among mobile devices and Home Agents and Correspondent Nodes. These protocol headers carry Mobile IPv6 Binding messages as well as Return Routability [2] messages. Currently the specification does not allow transport packets along with the mobility protocol header. Thus mobility protocol header can be accessed through IPv6 RAW sockets. A IPv6 RAW socket that is opened for protocol IPPROTO_MH should always be able to see all the MH (Mobility Header) packets. It is possible that future applications may implement part of Mobile IPv6 signal processing at the application level. Having a RAW socket interface may also enable an application to execute the Return Routability protocol or other future authentication protocol involving mobility header at the user level. 4.1 Receiving and Sending Mobility Header Messages This specification recommends IPv6 RAW sockets mechanism to send and receive Mobility Header (MH) packets. The behavior is similar to ICMPV6 processing, where kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation kernel may process the mobility header as well in addition to passing the mobility header to the application. If IPV6_CHECKSUM socket option is set on the RAW socket, kernel will calculate the checksum by default and place it on the mobility header before sending it out. Similarly, if IPV6_CHECKSUM is set, the protocol stack will verify the MH checksum on the inbound path and it will discard any MH packet with invalid checksums. Mobility Header checksum procedure is described in Mobile IPv6 Protocol [2] specification. Thus when IPPROTO_MH is used as the protocol field in the RAW socket() call and IPV6_CHECKSUM option is not set, the application needs to fill the checksum field of the mobility header for outbound data. Similarly the application needs to do checksum validity check for the received packet. Note that it is recommended that the application set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH. As an example, a program that wants to send or receive mobility header protocol(MH), could open a socket as following: fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH); int offset = 4; setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 12] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 If the program likes to handle HOTI/HOT and COTI/COT message processing, it can do so by using IPv6 RAW Sockets for IPPROTO_MH. The same application may also set IPV6_RECVDSTOPTS socket option for receiving home address option in a binding update [2] from the mobile node. 5. Protocols File Many hosts provide the file /etc/protocols that contains the names of the various IP protocols and their protocol numbers. The protocol numbers are obtained through function getprotoXXX() functions. The following addition should be made to the /etc/protocols file, in addition to what is defined in section 2.4 of Advanced Sockets API for IPv6 [1]. The protocol number for Mobility is pending IANA (http://www.iana.orgassignments/protocol-numbers) assignment. ipv6-mh 62(?) # Mobility Protocol Header 6. IPv4-Mapped IPv6 Addresses The same rule applies as described in section 13 of IPv6 Advanced API for Sockets [1]. Thus processing of IPv4-mapped IPv6 addresses for the MobileIPv6 specific socket options are out of scope of this document. 7. Security Considerations The setting of Home Address Destination option and route header Type 2 IPV6_RTHDR socket option may not be allowed at the application level in order to prevent denial-of-service attacks or man in the middle attacks by hackers. Sending and receiving of mobility header messages are possible by IPv6 RAW sockets. Thus it is assumed that this operation is only possible by priviledged users. However, it does not prevent the existing security threat by a hacker sending bogus mobility header or other IPv6 packets using home-address option and Type 2 routing extension header. draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 13] INTERNET-DRAFT Extension to Sockets API for MIPv6 February, 2003 8. References [1] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt April 19, 2002. [2] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-20.txt, January, 2003. [3] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, Dec. 1998. 9. Authors' Addresses Samita Chakrabarti Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054, USA Email: samita.chakrabarti@Sun.com Erik Nordmark Sun Microsystems Laboratories 180, avenue de l'Europe 38334 SAINT ISMIER Cedex, France Email: Erik.Nordmark@sun.com draft-chakrabarti-mobileip-mipext-advapi-00.txt [Page 14] --Drift_of_Hogs_283_000-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 19:13:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P3DK7f012250; Mon, 24 Feb 2003 19:13:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P3DKRB012249; Mon, 24 Feb 2003 19:13:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P3DG7f012242 for ; Mon, 24 Feb 2003 19:13:17 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1P3DPVK026694 for ; Mon, 24 Feb 2003 19:13:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25273 for ; Mon, 24 Feb 2003 19:13:19 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 03:13:12 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 03:11:32 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 03:13:11 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 03:13:10 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id A0A13146C0; Tue, 25 Feb 2003 14:13:08 +1100 (EST) Date: Tue, 25 Feb 2003 14:13:08 +1100 From: "Nick 'Sharkey' Moore" To: IPV6 WG Cc: Jari Arkko Subject: Re: RFC 3041 clarification requested Message-Id: <20030225031308.GA6380@zoic.org> Mail-Followup-To: IPV6 WG , Jari Arkko References: <3E4D07E1.3010205@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E4D07E1.3010205@kolumbus.fi> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Feb 14, 2003 at 05:14:41PM +0200, Jari Arkko wrote: > > I'm trying to understand what the following text means and > implies in Section 3.3 of RFC 3041: > > "Note: because multiple temporary addresses are generated from the > same associated randomized interface identifier, there is little > benefit in running DAD on every temporary address. This document > recommends that DAD be run on the first address generated from a > given randomized identifier, but that DAD be skipped on all > subsequent addresses generated from the same randomized interface > identifier." G'day Jari, well, I'm not the author but I can hazard a guess that this is referrring to the bit of RFC2462 5.4 which says "[...] an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier". > Does this refer to multiple addresses when the link has multiple > prefixes? Or when multiple temporary addresses are generated in > sequence? The former, including the Link-Local Prefix. In practise, a node implementing 3041 would choose an II, create a Link-Local Address (LLA) from that II, DAD for the LLA, and then just assume that any other addresses formed from that II are fine. Always doing the LLA first gets around the ordering problem you mention, too. > Also, it wasn't clear to me whether link-local addresses are > generated for every new IID or not. If they are, RFC 2462 > rules in Section 5.4 apply and the collision problem may > be solved that way. (Or does it -- where does it say that > "first" in 3041 refers to the link-local address?) I can't find this mentioned explicitly in 3041, no. Which it probably should be. I've been kicking some of these ideas around myself, see draft-moore-ipv6-optimistic-dad-02. cheers, -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 20:09:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P49p7f012543; Mon, 24 Feb 2003 20:09:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P49pgc012542; Mon, 24 Feb 2003 20:09:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P49l7f012535 for ; Mon, 24 Feb 2003 20:09:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1P49oVK007622 for ; Mon, 24 Feb 2003 20:09:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19730 for ; Mon, 24 Feb 2003 20:09:44 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 04:09:43 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 04:09:31 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 04:09:31 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 04:09:31 Z Content-class: urn:content-classes:message Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 2003 20:09:30 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Thread-Index: AcLb3sTVmlZvIoOMQGqICOs/G7sh6AApHwzA From: "Michel Py" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: "Pekka Savola" , "Alan E. Beard" , "Tim Chown" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1P49l7f012536 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Kurt Erik Lindqvist wrote: > This I thought was more or less standard. I was talking about > less than 100ms convergence. Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 ms rtt. You might need to talk to a guy named Albert Einstein; he wrote interesting RFCs about the speed of light that, as far as I know, have not been debunked yet. 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 24 22:21:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6LS7f013215; Mon, 24 Feb 2003 22:21:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P6LSb2013214; Mon, 24 Feb 2003 22:21:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6LP7f013207 for ; Mon, 24 Feb 2003 22:21:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1P6LXVK029584 for ; Mon, 24 Feb 2003 22:21:33 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07260 for ; Mon, 24 Feb 2003 23:21:27 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:21:27 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:21:26 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:21:26 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:21:25 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6Kg125443; Tue, 25 Feb 2003 08:20:42 +0200 Date: Tue, 25 Feb 2003 08:20:42 +0200 (EET) From: Pekka Savola To: Michel Py cc: Kurt Erik Lindqvist , Iljitsch van Beijnum , "Alan E. Beard" , Tim Chown , , Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@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 Mon, 24 Feb 2003, Michel Py wrote: > > Kurt Erik Lindqvist wrote: > > This I thought was more or less standard. I was talking about > > less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. When multi-connecting, such RTT's seem reasonable. If you need to converge on the global routing table, that's a non-starter of course -- but that's one of the main strengths of multi-connecting. No changes to those outside of the ISP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 22:38:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6cA7f013423; Mon, 24 Feb 2003 22:38:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P6cAdL013422; Mon, 24 Feb 2003 22:38:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6c77f013415 for ; Mon, 24 Feb 2003 22:38:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1P6cFVK002281 for ; Mon, 24 Feb 2003 22:38:15 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07418 for ; Mon, 24 Feb 2003 23:38:09 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:38:09 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:36:29 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:38:08 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:38:08 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6Tmq25476; Tue, 25 Feb 2003 08:29:51 +0200 Date: Tue, 25 Feb 2003 08:29:48 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <001901c2dc32$7a55e400$38e62a0f@nt23056> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: > > That is, the requesting router is in charge of all the prefixes until > > they expire. The robust requesting router implementation will perform > > some sane refreshing of these bindings way before they expire, even > > periodically. > > > > Thus, I fail to see any reason why these values would have to be > > communicated from the delegator. > > Yes, I agree that the it can refresh the bindings at any periodic > intervals it want. But, what if the delegating router is dead > and not responding at all? Then it will try again a bit later and succeed. > Hence, dhcpv6 provides you with > two values: > T1 -> This is the time at which the requesting router starts > contacting the delegating router for the renewal of the lease... > T2 -> If till the expiration of T2 it didn't get the response > from the delegating router, it can contact any available > dhcpv6 server to refresh its bindings. Do you mean that similar T1 & T2 values are being used by DHCP base spec? In that case I guess it's ok, but otherwise, I still fail to see the usability. > Ofcourse, the requesting router can generate these values itself. > With DHCPv6 server sending T1 and T2 values, the requesting > router dont need to recalculate the values again and again.. > Trust the DHCPv6 server, the values provided by it makes the > requesting router to refresh its bindings well before the expiry.. Well, typically the conventional wisdom is *not* to trust any external parties to any extent greater than necessary :-) > > Prefix delegation by DHCP is not meant to be > > all-purpose-zero-configuration tool for routers, I think. > > > > This seems conflicting -- a fringe case which should not came up. > > > > Better would be just require that the requesting router will get a > > delegation from all the ISP's for itself, and subnet accordingly. > > > > If the following does not apply, it seems to me that there > > must be routers > > connected to the downstreaming interfaces -- which in turn > > could perform > > prefix delegation directly from the ISP, the first router acting as a > > relay. > > > > Doesn't seem to be need for this.. > > Need not be. Simple case is Home networks, they dont afford to have > individual routers for every ISPs. They may need multiple ISPs > for high availablity or some other reason. In this case, there will > be only one border router with mutiple appliances/nodes in the > downstreaming interfaces, which may span in one or more links. > In this case, it needs to unique IA_PD for every ISP. Seems a bit far-fetched, IMO, but ok.. > > Regardless of that, I'm not sure how the requesting router would > > discover more of these delegating routers -- how would they be > > connected? Which kind of infrastructure would typically be between > > requesting router and multiple delegating routers? > > I beleive there will be unique dialup connection with each ISPs. .. as above, I've yet to see dial-up routers deployed which would have two dial-out adapters and phone jacks, but ok.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 24 22:49:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6nK7f013664; Mon, 24 Feb 2003 22:49:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1P6nK3j013663; Mon, 24 Feb 2003 22:49:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1P6nH7f013656 for ; Mon, 24 Feb 2003 22:49:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1P6nPVL017762 for ; Mon, 24 Feb 2003 22:49:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12011 for ; Mon, 24 Feb 2003 23:49:19 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:49:19 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:47:39 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:49:19 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 06:49:18 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6n0W25598; Tue, 25 Feb 2003 08:49:00 +0200 Date: Tue, 25 Feb 2003 08:49:00 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030224140504.03f26948@funnel.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Similar discussion has already been had, so I'll try to keep it at the minimum. On Mon, 24 Feb 2003, Ralph Droms wrote: > At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: > >On Tue, 11 Feb 2003, Ralph Droms wrote: > > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > > > options and a mechanism through which a "delegating router" (e.g., an ISP > > > aggregation device) can assign and delegate one or more prefixes to a > > > "requesting router" (e.g., CPE). This draft is available as > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > >A few comments. > > > >Bigger issues -- I'm sorry for bringing them up so late (relatively), but > >I haven't really thought/read about the big picture, before. > > > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > >mostly redundant -- the requesting router should just take the minimum of > >lifetimes of the prefixes, calculate it in the same fashion, that's it. > >Of course, there is an assumption (which doesn't seem to be properly > >addressed!) that the requesting router is free to refresh the delegation > >when it feels right, even every hour, day, month etc. without regard to > >the lifetimes -- indeed, I think *NO* implementation would just wait until > >the last minute to refresh them. > > > >Is there something I'm missing? > > The spec allows for flexibility in deployment scenarios by > allowing the ISP (through the delegating router) to control > the behavior of the requesting router, or by leaving the > behavior under the control of the requesting router > by setting T1 and T2 to 0 (see section 8 of the draft). Yes, I noticed they can be zero -- all I'm questioning is the usability of this flexibility. I fail to see why such flexibility is useful. The requesting router can be as flexible as it wants -- and refresh bindings when it deems it necessary even without guidance. > >2) Multiple IA_PD looks unnecessarily complex. Are there any valid > >reasons why it wouldn't be just enough to have only one IA_PD per > >requesting router? (The option to and subsequent complexity of) > >generating one for each interface seems like a completely unnecessary > >feature to me -- it's the router which should be doing prefix delegation > >to it's downstream interfaces! > > > >The only feature I can quickly think of which could profit from this is > >kind of "shared routers" where the connected interfaces are separate > >administrative entities with differently configured properties at the ISP. > >This seems questionable to me, a case for manual configuration or > >"advanced prefix delegation" to me. > > > >So, I think the possibility to do prefix delegation in more complex ways > >than really necessary should be seriously considered. Keep it Simple, > >Stupid would be a good rule. > > There is no requirement that the delegating router supply more than > one IA_PD to the requesting router, and limiting the delegation to > only one IA_PD seems overly restrictive. For example, a delegating > router might send one IA_PD for each ISP used by a customer site. I don't see it overly restrictive myself: as an operator and end-user, if someone connects to two ISP's, it's (almost, at least) always done either from two separate routers (no use doing it from one, really), or in a serial fashion (terminate one, establish the other -- like dialup). > It is not the intention of the draft that the requesting router > receive one IA_PD for each of its downstream interfaces. If that > is your understanding of the draft, then we need to clarify > the text. In section 11.1, the draft specifies that the > requesting router assigns subnets from the delegated prefixes > to each of its downstream interfaces. I understood well that the particular behaviour is only optional, but the problem seems to be that the "main behaviour" is described quickly (indeed, it's rather simple) and then the spec goes on at great length describing the fringe cases. This makes an unwary reader think the fringe cases are actually more than just fringe cases. At least, there should be some clearer separation between the two and possibly some guidance when (for example) not to use special mechanisms. > >3) One item that may also need some consideration is the option to let the > >requesting router give its preference to some values (prefix length, > >lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not > >sure of the usefulness of these, really. In the real world, I think ISP's > >set them, either to some values communicated off-band, or otherwise. The > >complexity required (policy, policy,...) when the delegating router must > >decide whether it can agree to the requested values seems like a big hit. > >I'm not really sure whether it's worth it, even though it may offer some > >flexibility for some corner cases. The only commonly used one I could > >think of would be whether the customer wants _single_ /64 (for the only > >one subnet!) or whole /48 -- seems like a heavy baggage for that. > > The cost of allowing the requesting router to express its preferences > isn't all that great - a simple delegating router can simply ignore > the requesting router's preferences... Certainly. I see this as a potential problem from two directions: 1) delegating router handling untrusted input values, creating delegations based on them, and 2) the requesting router requesting something that architectually differs *a lot* from what's given (example: /64's directly for its interfaces, and one /48 delegated). Then what? Can the requesting router handle this kind of situation? The problem is that entering preferences *in-band* (instead of out-of-band, as usual) seems problematic, as it creates difficult situations at both ends in the cases the preferences are not met (and policy decisions even if met). At the very least, one should clarify something along the lines of "In any case, the requesting router MUST NOT depend on any of its preferences to be honored" if this feature is really necessary. > > option-code: OPTION_IA_PD (TBD) > > > > option-length: 12 + length of IA_PD-options field. > > > >==> is it necessary to say how the option-code is stored/transported > >(signed/unsigned) ? I guess this is clear enough? > > The format of the option code is (should be?) specified in the > DHCPv6 spec. Ok -- it's just that AFAICS, I don't see that a connection has been made between the two (even if they use the same name). > > The requesting router MUST ignore any Advertise message that includes > > a Status Code option containing the value NoPrefixAvail, > > > >==> where is the defintion of NoPrefixAvail or other codes? > > Needs a pointer to the DHCPv6 spec? At the minimum. > > message for the user, a Server Identifier option with the delegating > > router's DUID and a Client Identifier option with the requesting > > router's DUID. > > > >==> DUID used for the first time (inherited from DHCPv6 spec I think), > >spell it out? > > Needs a pointer to the DHCPv6 spec? Yes please, and spell out the abbreviation in the text (no need to put it up in terminology IMO). > > When a requesting router subnets a delegated prefix, it must assign > > additional bits to the prefix to generate unique, longer prefixes. > > For example, if the requesting router in Figure 1 were delegated > > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > > 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber > > network. > > > >==> I'm not sure if the first sentence is entirely accurate. One could > >use prefix delegation to get multiple /64's directly from your ISP, then > >extra bits wouldn't be needed at all. > > But that wouldn't be "subnetting", I don't think - just reassignment? Ah, got me there :-). The problem with the language seems to be that even though it says "when ... subnets", there are no other "whens" so this paragraph is taken to imply all of it (especially since the main form of prefix delegation always includes subnetting, as noted earlier in the draft). > >14. Security Considerations > > > >==> personally I'm rather worried about the requestor being able to give > >"guidance" to the delegator what on what it wants. Unreliable input could > >lead to bad results in an implementation which hasn't been done carefully > >(requesting link/site-local prefixes which don't exist, effect of bogus > >prefixlengths etc.etc.). [more of this was above] > > Paranoid delegating routers can simply ignore the guidance... Yep, put that in there :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 03:29:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PBTA7f014537; Tue, 25 Feb 2003 03:29:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PBTAtc014536; Tue, 25 Feb 2003 03:29:10 -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.8+Sun/8.12.8) with ESMTP id h1PBT67f014529 for ; Tue, 25 Feb 2003 03:29:06 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1PBT4P04482; Tue, 25 Feb 2003 12:29:05 +0100 (MET) Date: Tue, 25 Feb 2003 12:25:13 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix" To: Michel Py Cc: Erik Nordmark , Alain Durand , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <963621801C6D3E4A9CF454A1972AE8F54C34@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 > The idea is that developers must not hardcode any assumptions. The > reason they must not is because IANA will later delegate the currently > unassigned parts of the space to a purpose we don't know, including > possibly an extension to Global Unicast. The proposed text reads as if the IANA delegation is the main point and the implementation note being just a side note. So if the implementation concern is the main point of the paragraph why not say this explicitly with something like Even though currently only 2000::/3 is being delegated by the IANA, implementations should not make any assumptions about 2000::/3 being special, since the IANA might later delegate currently unassigned parts of the IPv6 address space to the purpose of Global Unicast as well. 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 25 05:02:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PD2c7f015508; Tue, 25 Feb 2003 05:02:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PD2cjt015507; Tue, 25 Feb 2003 05:02:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PD2Z7f015500 for ; Tue, 25 Feb 2003 05:02:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PD2iVK009935 for ; Tue, 25 Feb 2003 05:02:44 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18585 for ; Tue, 25 Feb 2003 06:02:38 -0700 (MST) From: jarno.rajahalme@nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 13:02:38 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 13:00:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 13:02:38 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 13:02:37 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1PD5gm21912 for ; Tue, 25 Feb 2003 15:05:42 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 15:02:34 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 15:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt Date: Tue, 25 Feb 2003 15:02:33 +0200 Message-Id: <009CA59D1752DD448E07F8EB2F9117570216EB4F@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt Thread-Index: AcLAoc1kVnO0mqEETGKnKg1TX3if1wcJqnGA To: Cc: , X-OriginalArrivalTime: 25 Feb 2003 13:02:33.0961 (UTC) FILETIME=[29A15D90:01C2DCCE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1PD2Z7f015501 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, See my comments inline: > > > > We don't know, and 60 seconds is a compromise value anyway. > > > But there > > > > seemed to be WG consensus that a default timeout is > needed, since > > > > otherwise we are licensing implementors to create hard > > > state. The authors > > > > have been round and round this many times, and this was > the best we > > > > could come up with. (more comment on this below) > > > > > > Well, I have a basic problem with a default timeout of 60 > > > seconds. Heck, a temporary routing glitch can cause a > loss of traffic > > > for 60 seconds, yet the TCP sesssion doesn't go away that > quickly. So > > > 60 seconds seem like a rather odd compromise value. Seems > too short to > > > me. > > > > > > Presumably the node can re-create the state it needs after the > > gap. Since there was a long gap, there should be no reordering > > issues (in case the new state for example determines a different > > next-hop interface). > > > For reference, RFC 1883 defined a lifetime value of 6 seconds. > > Not really relevant, as that had to do with the now discredited > opportunistic caching that is explicitely deprecated by this document. > Well, IMO the default lifetime has no other function than enabling opportunistic caching (if everything is based on a explicit set-up, the lifetime for each flow can be set up individually, and no default is needed). As a consequence of adding the default lifetime, I removed the "SHOULD NOT" that prohibited setting up state without a set-up mechanism. > > As I said above, I do not know any use of flow-specific state > > without the support of a flow state establishment method. But if we > > do not define a default lifetime now, it cannot be added > > later. Also, it seems logical to have *some* pause before a > > previously used flow label value should be re-used for a new flow. > > I don't necessarily disagree with the need for a default lifetime. But > I think 60 seconds is too short. It seems to me that it would be > better to tie it to something more meaningful, like TCP lifetimes. At > least, if we're just picking a value out of the hat. Why is 60 seconds > better than 2 minutes? Why is 2 minutes wrong compared to 1 minute? > > Let me state it differently. What I'm hearing is that we want a > default, but that 60 seconds has been pulled out of thin air. I can't > evaluate whether that is a good default or not, because I don't > understand the tradeoffs. I'm arguing that its too short, but the > reasons for keeping it short don't seem (to me) to be very > rigorous. What are the tradeoffs here that would lead one to pick a > longer or shorter value? Some thoughts: > > There is a cost associated with a short default, in that routers will > be forced to rebuild the flow state more frequently. Given that > temoporary routing issues can easily last more than a 60 seconds, and > that a normal TCP connection/flow will sometimes not send traffic for > 60 seconds, I worry that this cost is relatively high. Is that cost > justified? > > There is also a cost for the default being longer on hosts, as they > need to not reuse flow labels too quickly. The issue seems most acute > across reboots. Is it substantially more overhead for a host to not > reuse a flow label for (say 5 minute) vs. one minute? I don't think > so. > > Are there other issues that should be considered here? > If e.g. random initial value and sequential allocation is acceptable after reboot, then there is no additional cost to the host on even longer than a few minute timeouts. But a short default timeout should not be a burden on routers either. There are two cases: 1) opportunistic set-up: the overhead of setting up the state must be negligibly small, as the router needs to be prepared to set up state for each incoming packet (in the worst case scenario). If so, the difference between 1 and 2 minute default lifetime should be of no consequence 2) Flow set-up with a flow set-up mechanism: The mechanism can set whatever lifetime it wants. If the mechanism is concerned by TCP timeouts, then the minimum lifetime being set up with that mechanism is likely to be 2 minutes (?). Some other mechanisms could utilize lifetimes considerably longer (e.g. 1 hour), depending on the cost of setting up and maintaining the state with that mechanism. My take is that for 2) the default lifetime value has no real meaning (other than hosts need to keep the labels in quarantine for the default duration, even if the flow set-up resulted in a shorter lifetime, because there could be a node in the path not taking part in the mechanism, but opportunistically caching the flow). For 1) even 6 seconds should be fine. > > WG chairs (collectively) insisted on the definition of the default > > lifetime, and there were no opposing voices on this from the WG. > > > I do not think the default lifetime should have anything to do with > > TCP timeouts, as long as it is long enough to not cause any > > reordering issues. But this is not an issue for me, any value is > > fine, especially if someone could come up with good justification > > for the value :-) > > The comment about reordering suggests some reason for a particular > value. But I don't understand what the reording issue is. In general, > we don't want to reorder packets. Not good for TCP. But reording can > happen, and it doesn't break things if it's a transient issue. What > reordering issues occur with flow state? If I understood the issue > better, it might lead me to agree that 60 seconds makes sense. But I > don't have a good handle on the underlying issue. What I referred to as reordering issue is that if some node is making a forwarding decision based on the flow identity (some form of load balancing), the packets of the flow should remain in the same path. But if there is a gap of couple of seconds between the packets, there would be no re-ordering even if the path for packets after the gap is different. This assuming that packets will not stay in the network for many seconds. > > Thoughts? > According to what I have presented above, minimum default lifetime we can consider is "a couple of seconds". There is no hard upper limit. To keep grounded on something I understand, I have proposed shorter rather than longer timeouts. But I'm open to any suggestions. Would everyone be happy with 2 minutes? > > > > > What problem is the above wording intended to address? > > > > > > > Use cases that nobody has thought of yet. > > > > > > I don't understand this answer. If a router does something > > > flow-specfic for flow X, but then sees no traffic for 60 > seconds, the > > > implication now is that it shouldn't give flow X the same > treatement > > > it was just giving it just 60 seconds ago. > > > > > > No. It would still give the flow X, but it would just need to re-use > > s/would/could/? If it will continue giving the flow X, what was the > point of re-creating X? > > > the algorithm/method/whatever to re-create the X after the gap, if > > it flushed the X. > > > It might be likely that X is not really flow-specific, but can be > > applied to aggregates of flows. In this case there is no point in > > flushing the X (ever). > > > > > > > 3. Flow Labeling Requirements > > > > > > > > > > > > To enable Flow Label based classification, sources > > > SHOULD assign each > > > > > > unrelated transport connection and application data > > > stream to a new > > > > > > flow. The source MAY also take part in flow state > > > establishment > > > > > > methods that result in assigning certain packets to > > > specific flows. A > > > > > > source which does not assign traffic to flows MUST > > > set the Flow Label > > > > > > to zero. > > > > > > > > You left the 2nd paragraph out from your quote. I think it should be > > considered here as well: > > > "To enable applications and transport protocols to define > what packets > > constitute a flow, the source node MUST provide means for the > > applications and transport protocols to specify the Flow > Label values > > to be used with their flows. The source node SHOULD be > able to select > > unused Flow Label values for flows not requesting a > specific value to > > be used." > > OK. I still find the wording a bit confusing though. Maybe it's > because of the use of the term "source". Source can mean application, > or the IP stack or the host as a whole. Above, I guess it means "IP > stack", but I have to think about this before coming to that > conclusion. It might be better to be even more precise. > Further comment on this? > > > Note: this last sentence seems hard to achieve. it > suggests that if a > > > future flow establishment method uses longer lifetimes, > the stack will > > > have to be retrofitted to figure out somehow not to reuse > those flow > > > label values for the longer period. I suspect that future > uses of the > > > flow label (i.e., the signalling partz) may well be implemented > > > separately from the base IP stack Flow Label support, and > it may not > > > be possible for the signalling to ensure the quarantine behavior. > > > > > > There are at least two ways to implement this: > > > 1) the stack implementation allows the application (or any > > middleware on top of the stack) to define the lifetime, that the > > stack will then honor (e.g. by not assigning that value to any new > > flow for the timeout value after all sockets belonging to that flow > > have been closed), possibly individually for the flow, or by > > utilizing the longest timeout for all flows. > > > 2) In the absence of the interface for the non-default lifetime, the > > FSEM could keep the flow "reserved" for timeout-60 seconds after the > > flow's traffic has finished, and only after that release the label > > back to the stack (which would then keep the value reserved for the > > normal 60 seconds). > > I agree the above can be done. Do you really expect implementations to > do 1) above based on the wording in the current spec? I have my > doubts. > Suggestions on this? > > How about: > > > "The requirement of not reusing a Flow Label value for a > new flow with > > the same pair of source and destination addresses extends across > > source node crashes and reboots. To avoid accidental Flow > Label value > > reuse, the source node SHOULD select new Flow Label values > in a well- > > defined sequence (e.g. sequential or pseudo-random) and use a > > different initial value for the sequence each time the > system starts. > > The initial value could be randomly generated, or computed from a > > previous value stored in non-volatile memory." > > Better, but still not quite right. If the machine has no stable > storage for remembering previous values, the random approach is the > best we can do. But for those with stable storage, random is > presumbaly less desirable, and the new value should be based on > previous history. If that is what we want to recommend, it would be > better to just say so. It is also not enough that it uses a > "different" initial value from the previous initial value, it needs to > be one that avoids collisions with recently previously used flow > IDs. E.g., something like: > > To avoid accidental Flow Label value reuse, the source node SHOULD > select new Flow Label values in a well-defined sequence > (e.g. sequential or pseudo-random) and use an initial value that > avoids reuse of recently used Flow Label values each time the > system restarts. The initial value should be derived from a > previous value stored in non-volatile memory, or in the absence of > such history, a randomly generated initial value using techniques > that produce good randomness properties [RFC 1750???]. > Agree. Will check if the reference is right. Jarno -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 05:32:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PDWA7f015992; Tue, 25 Feb 2003 05:32:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PDWAt2015991; Tue, 25 Feb 2003 05:32:10 -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.8+Sun/8.12.8) with ESMTP id h1PDW67f015984 for ; Tue, 25 Feb 2003 05:32:06 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1PDW7P11170; Tue, 25 Feb 2003 14:32:08 +0100 (MET) Date: Tue, 25 Feb 2003 14:28:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Mika Liljeberg Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1046109510.6109.13.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well, this was only proposed for TCP. I don't know what "this" refers to but the original message from Pekka commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to those comments. That draft has this in the abstract: Today, the use of IPv6 anycast is limited. This document proposes a mechanism by which TCP/SCTP and stateful protocols using UDP can So the draft fron Brian and me sure proposes using this for more than just TCP. > I'm not sure if we should consider > something similar for UDP. Basically, UDP based protocols can be easily > written to handle the peer address change on the application layer. > However, if we want to support existing UDP applications that for > example connect() their socket to a destination address, we'd need to > device something similar for UDP as well. Do you think we need this? I don't know about "easily" - they would need to provide the secure binding mechanism themselves. I think it makes sense to try to figure out a mechanism which can be applied to multiple "stateful" protocols without requiring every such protocol to roll their own. At one end of the scale one could consider doing do changes to the transport at all by hiding it all in a MIPv6 binding cache. Thus the transport protocol would think it is actually talking to the anycast address. I think such an approach has problems since the fact that the transport is not aware that anycast is used means it can't take specific actions when things fail (like trying to create a binding to a different member of the anycast address). Providing this "transport protocol aware anycast model" means that there will be some changes to the transport protocol, but I think one can avoid placing all the mechanisms in each transport protocol. 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 25 06:27:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PERM7f016240; Tue, 25 Feb 2003 06:27:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PERLVf016239; Tue, 25 Feb 2003 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PERI7f016232 for ; Tue, 25 Feb 2003 06:27:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PERRVL000822 for ; Tue, 25 Feb 2003 06:27:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19693 for ; Tue, 25 Feb 2003 06:27:21 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 14:27:20 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 14:27:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 14:27:20 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 14:27:19 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1PER6Ct035312; Tue, 25 Feb 2003 15:27:08 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1PEQvTT260798; Tue, 25 Feb 2003 15:26:57 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44744 from ; Tue, 25 Feb 2003 15:26:55 +0100 Message-Id: <3E5B7CFA.478846BB@hursley.ibm.com> Date: Tue, 25 Feb 2003 15:26:02 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: jarno.rajahalme@nokia.com Cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt References: <009CA59D1752DD448E07F8EB2F9117570216EB4F@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: ... > Would everyone be happy with 2 minutes? I would. 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 Tue Feb 25 10:10:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PIAr7f016998; Tue, 25 Feb 2003 10:10:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PIAqH0016997; Tue, 25 Feb 2003 10:10:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PIAn7f016990 for ; Tue, 25 Feb 2003 10:10:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PIAwVK029269 for ; Tue, 25 Feb 2003 10:10:58 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21504 for ; Tue, 25 Feb 2003 10:10:52 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 18:10:46 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP; Tue, 25 Feb 2003 18:10:46 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Tue, 25 Feb 2003 18:10:46 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP; Tue, 25 Feb 2003 18:10:45 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1PIATaj020698; Tue, 25 Feb 2003 20:10:30 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1PIAPIf020695; Tue, 25 Feb 2003 20:10:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: a few comments on anycast mechanisms From: Mika Liljeberg To: Erik Nordmark Cc: Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046196624.15624.54.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 20:10:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-02-25 at 15:28, Erik Nordmark wrote: > > Well, this was only proposed for TCP. > > I don't know what "this" refers to but the original message from Pekka > commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to > those comments. > > That draft has this in the abstract: > Today, the use of IPv6 anycast is limited. This document proposes a > mechanism by which TCP/SCTP and stateful protocols using UDP can > > So the draft fron Brian and me sure proposes using this for more than > just TCP. Right, I had forgotten where the thread started. I was referring to Pekka's idea of using an ICMP error response as a simple redirect indication to a TCP sender and "authenticating" the ICMP packet by checking the TCP sequence number in the ICMP payload. > > I'm not sure if we should consider > > something similar for UDP. Basically, UDP based protocols can be easily > > written to handle the peer address change on the application layer. > > However, if we want to support existing UDP applications that for > > example connect() their socket to a destination address, we'd need to > > device something similar for UDP as well. Do you think we need this? > > I don't know about "easily" - they would need to provide the secure binding > mechanism themselves. TCP has the problem that it simply can't be used with an anycast address without changing the protocol or somehow handling the binding transparently on L3 (as in MIPv6). UDP doesn't have this problem; at most the applications need to be changed to react correctly to peer address change. I didn't consider the above from the viewpoint of authenticating the binding. I can see that the authentication could get quite involved with UDP. I'm not sure it's wise to do it transparently in all cases. I guess the RR mechanism could be adapted but there are some problems. Some of the problems relate to figuring out what constitutes a session with a UDP application. A connectionless socket could be used to communicate simultaneously with multiple peers, the protocol could just be a one-shot request-reply interaction, or the flows could be uni-directional, etc. Also, as I pointed out earlier, the RR mechanism in MIPv6 affords the CN some protection against DoS at the expense of the MN. In draft-haberman-ipv6-anycast-rr-00 the anycast server takes the role of the MN, which means that it draws the short straw when it comes to DoS protection. > I think it makes sense to try to figure out a mechanism which can be applied > to multiple "stateful" protocols without requiring every such protocol > to roll their own. That's a good goal. Different applications might have different requirements, though. Some might require that the binding is authenticated, while others might value a speedy redirect, even if unsafe. > At one end of the scale one could consider doing do changes to the transport > at all by hiding it all in a MIPv6 binding cache. Thus the transport > protocol would think it is actually talking to the anycast address. > I think such an approach has problems since the fact that the transport is > not aware that anycast is used means it can't take specific actions when > things fail (like trying to create a binding to a different member of > the anycast address). True. It is also worth asking what is the proper granularity for storing the binding: per host, per flow, or something in between? Do we want to redirect all applications to the same unicast address, or should we allow different flows go to different unicast addresses? > Providing this "transport protocol aware anycast model" means that there > will be some changes to the transport protocol, but I think one can > avoid placing all the mechanisms in each transport protocol. Maybe some basic L3 mechanisms, like the binding cache and RR, could be made available to applications and transport protocols as a "toolbox" via an appropriate service interface. Each "anycast user" could then use this toolbox in the most appropriate way. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 10:26:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PIQc7f017329; Tue, 25 Feb 2003 10:26:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PIQb4g017328; Tue, 25 Feb 2003 10:26:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PIQY7f017321 for ; Tue, 25 Feb 2003 10:26:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PIQhVK004886 for ; Tue, 25 Feb 2003 10:26:43 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06013 for ; Tue, 25 Feb 2003 11:26:38 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 18:26:37 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 18:26:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 18:26:37 Z Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 18:26:36 Z Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1PIQWYE006504 for ; Tue, 25 Feb 2003 10:26:33 -0800 (PST) Received: from SIVAV.qualcomm.com (sivav.qualcomm.com [129.46.222.34]) by crowley.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1PIQV5O004144 for ; Tue, 25 Feb 2003 10:26:31 -0800 (PST) Message-Id: <4.3.2.7.2.20030225101949.0452e488@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 10:26:29 -0800 To: ipng@sunroof.eng.sun.com From: Siva Veerepalli Subject: Site-local clarification In-Reply-To: <3E5B7CFA.478846BB@hursley.ibm.com> References: <009CA59D1752DD448E07F8EB2F9117570216EB4F@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_50749974==_.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_50749974==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Sec 2.5.6 of the site-local addressing architecture states that: Site-Local addresses have the following format: | 1111111011 | 54 bit subnet ID | 64 bit Interface ID | Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes. Does the interpretation of the above sentence mean, "if my global prefix is 3FFE:2900:1107:314::/64, my site-local prefix would be FECE:2900:1107:314::/64" ? Thanks, Siva --=====================_50749974==_.ALT Content-Type: text/html; charset="us-ascii" Sec 2.5.6 of the site-local addressing architecture states that:

Site-Local addresses have the following format:

| 1111111011 | 54 bit subnet ID |  64 bit Interface ID |

Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes.

Does the interpretation of the above sentence mean, "if my global prefix is 3FFE:2900:1107:314::/64, my site-local prefix would be FECE:2900:1107:314::/64" ?

Thanks,
Siva
--=====================_50749974==_.ALT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 11:06:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJ6M7f017824; Tue, 25 Feb 2003 11:06:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PJ6Mud017820; Tue, 25 Feb 2003 11:06:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJ6H7f017810 for ; Tue, 25 Feb 2003 11:06:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PJ6QVL026603 for ; Tue, 25 Feb 2003 11:06:26 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23722 for ; Tue, 25 Feb 2003 12:06:20 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:06:20 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:06:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:06:20 Z Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:06:19 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id CE7A41C0178F; Tue, 25 Feb 2003 11:06:16 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id AAA14218; Wed, 26 Feb 2003 00:35:33 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" Cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Wed, 26 Feb 2003 00:34:49 +0530 Message-Id: <001e01c2dd00$c5e3bbd0$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:00 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: > > > That is, the requesting router is in charge of all the > prefixes until > > > they expire. The robust requesting router implementation > will perform > > > some sane refreshing of these bindings way before they > expire, even > > > periodically. > > > > > > Thus, I fail to see any reason why these values would have to be > > > communicated from the delegator. > > > > Yes, I agree that the it can refresh the bindings at any periodic > > intervals it want. But, what if the delegating router is dead > > and not responding at all? > > Then it will try again a bit later and succeed. The time "bit later" is well defined by DHCPv6 base architecture. > > > Hence, dhcpv6 provides you with > > two values: > > T1 -> This is the time at which the requesting router starts > > contacting the delegating router for the renewal of the lease... > > T2 -> If till the expiration of T2 it didn't get the response > > from the delegating router, it can contact any available > > dhcpv6 server to refresh its bindings. > > Do you mean that similar T1 & T2 values are being used by > DHCP base spec? > In that case I guess it's ok, but otherwise, I still fail to see the > usability. Yes, T1 and T2 values are being used in DHCPv6 base spec. > > > Ofcourse, the requesting router can generate these values itself. > > With DHCPv6 server sending T1 and T2 values, the requesting > > router dont need to recalculate the values again and again.. > > Trust the DHCPv6 server, the values provided by it makes the > > requesting router to refresh its bindings well before the expiry.. > > Well, typically the conventional wisdom is *not* to trust any > external > parties to any extent greater than necessary :-) If you are able to trust the prefixes given by DHCPv6, then there will be no harm in trusting the time values provided by it :-) > > > > Prefix delegation by DHCP is not meant to be > > > all-purpose-zero-configuration tool for routers, I think. > > > > > > This seems conflicting -- a fringe case which should not came up. > > > > > > Better would be just require that the requesting router > will get a > > > delegation from all the ISP's for itself, and subnet accordingly. > > > > > > If the following does not apply, it seems to me that there > > > must be routers > > > connected to the downstreaming interfaces -- which in turn > > > could perform > > > prefix delegation directly from the ISP, the first router > acting as a > > > relay. > > > > > > Doesn't seem to be need for this.. > > > > Need not be. Simple case is Home networks, they dont afford to have > > individual routers for every ISPs. They may need multiple ISPs > > for high availablity or some other reason. In this case, there will > > be only one border router with mutiple appliances/nodes in the > > downstreaming interfaces, which may span in one or more links. > > In this case, it needs to unique IA_PD for every ISP. > > Seems a bit far-fetched, IMO, but ok.. > > > > Regardless of that, I'm not sure how the requesting router would > > > discover more of these delegating routers -- how would they be > > > connected? Which kind of infrastructure would typically > be between > > > requesting router and multiple delegating routers? > > > > I beleive there will be unique dialup connection with each ISPs. > > .. as above, I've yet to see dial-up routers deployed which > would have two > dial-out adapters and phone jacks, but ok.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 11:36:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJa97f020278; Tue, 25 Feb 2003 11:36:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PJa9bJ020277; Tue, 25 Feb 2003 11:36:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJa57f020270 for ; Tue, 25 Feb 2003 11:36:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PJaFVL009706 for ; Tue, 25 Feb 2003 11:36:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28825 for ; Tue, 25 Feb 2003 11:36:09 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:36:08 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:36:07 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:36:07 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:36:07 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1PJPuH30388; Tue, 25 Feb 2003 21:25:56 +0200 Date: Tue, 25 Feb 2003 21:25:55 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <001e01c2dd00$c5e3bbd0$38e62a0f@nt23056> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: > > > Ofcourse, the requesting router can generate these values itself. > > > With DHCPv6 server sending T1 and T2 values, the requesting > > > router dont need to recalculate the values again and again.. > > > Trust the DHCPv6 server, the values provided by it makes the > > > requesting router to refresh its bindings well before the expiry.. > > > > Well, typically the conventional wisdom is *not* to trust any > > external > > parties to any extent greater than necessary :-) > > If you are able to trust the prefixes given by DHCPv6, then there will be > no harm in trusting the time values provided by it :-) It's not about that kind of trust -- rather "I trust that the times provided to me by the operator are the best possible choices, and they have in fact provided them" -- I'd imagine you trust your own DHCPv6 implementation and configuration more than your ISP's. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 11:53:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJrd7f020585; Tue, 25 Feb 2003 11:53:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PJrdi7020584; Tue, 25 Feb 2003 11:53:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PJrY7f020574 for ; Tue, 25 Feb 2003 11:53:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PJriVL015589 for ; Tue, 25 Feb 2003 11:53:44 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03957 for ; Tue, 25 Feb 2003 12:53:38 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:53:37 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:53:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:53:37 Z Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 19:53:36 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id DE8CA1C00DC3; Tue, 25 Feb 2003 11:53:33 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id BAA16759; Wed, 26 Feb 2003 01:22:51 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" , "'Ralph Droms'" Cc: , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Wed, 26 Feb 2003 01:22:07 +0530 Message-Id: <002101c2dd07$6128d250$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:19 PM > To: Ralph Droms > Cc: dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: Re: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Similar discussion has already been had, so I'll try to keep > it at the > minimum. > > On Mon, 24 Feb 2003, Ralph Droms wrote: > > At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: > > >On Tue, 11 Feb 2003, Ralph Droms wrote: > > > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > describes new DHCPv6 > > > > options and a mechanism through which a "delegating > router" (e.g., an ISP > > > > aggregation device) can assign and delegate one or more > prefixes to a > > > > "requesting router" (e.g., CPE). This draft is available as > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- > prefix-delegation-02.txt > > > > > >A few comments. > > > > > >Bigger issues -- I'm sorry for bringing them up so late > (relatively), but > > >I haven't really thought/read about the big picture, before. > > > > > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > >mostly redundant -- the requesting router should just take > the minimum of > > >lifetimes of the prefixes, calculate it in the same > fashion, that's it. > > >Of course, there is an assumption (which doesn't seem to > be properly > > >addressed!) that the requesting router is free to refresh > the delegation > > >when it feels right, even every hour, day, month etc. > without regard to > > >the lifetimes -- indeed, I think *NO* implementation would > just wait until > > >the last minute to refresh them. > > > > > >Is there something I'm missing? > > > > The spec allows for flexibility in deployment scenarios by > > allowing the ISP (through the delegating router) to control > > the behavior of the requesting router, or by leaving the > > behavior under the control of the requesting router > > by setting T1 and T2 to 0 (see section 8 of the draft). > > Yes, I noticed they can be zero -- all I'm questioning is the > usability of > this flexibility. I fail to see why such flexibility is useful. The > requesting router can be as flexible as it wants -- and > refresh bindings > when it deems it necessary even without guidance. On reading your previous mail, i thought you have agreed with T1 and T2 :-) Probably, the routers which are "wise" enough to rely up of prefixes provided by the DHCPv6 server and "dumb" enough to trust the time values provided by it, may need this ;-) Perhaps, these T1 and T2 values exist from DHCPv4 architecture itself and worked successfully. If the requesting routers doesn't want to trust the time values, they can just ignore the T1 and T2 values and refresh the leases whenever it wishes. > > > >2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > >reasons why it wouldn't be just enough to have only one IA_PD per > > >requesting router? (The option to and subsequent complexity of) > > >generating one for each interface seems like a completely > unnecessary > > >feature to me -- it's the router which should be doing > prefix delegation > > >to it's downstream interfaces! > > > > > >The only feature I can quickly think of which could profit > from this is > > >kind of "shared routers" where the connected interfaces > are separate > > >administrative entities with differently configured > properties at the ISP. > > >This seems questionable to me, a case for manual configuration or > > >"advanced prefix delegation" to me. > > > > > >So, I think the possibility to do prefix delegation in > more complex ways > > >than really necessary should be seriously considered. > Keep it Simple, > > >Stupid would be a good rule. > > > > There is no requirement that the delegating router supply more than > > one IA_PD to the requesting router, and limiting the delegation to > > only one IA_PD seems overly restrictive. For example, a delegating > > router might send one IA_PD for each ISP used by a customer site. > > I don't see it overly restrictive myself: as an operator and > end-user, if > someone connects to two ISP's, it's (almost, at least) always > done either > from two separate routers (no use doing it from one, really), or in a > serial fashion (terminate one, establish the other -- like dialup). Simultaneous connection is also needed in some cases, as i told earlier, like, high availablity > > > It is not the intention of the draft that the requesting router > > receive one IA_PD for each of its downstream interfaces. If that > > is your understanding of the draft, then we need to clarify > > the text. In section 11.1, the draft specifies that the > > requesting router assigns subnets from the delegated prefixes > > to each of its downstream interfaces. > > I understood well that the particular behaviour is only > optional, but the > problem seems to be that the "main behaviour" is described quickly > (indeed, it's rather simple) and then the spec goes on at > great length > describing the fringe cases. This makes an unwary reader > think the fringe > cases are actually more than just fringe cases. > > At least, there should be some clearer separation between the two and > possibly some guidance when (for example) not to use special > mechanisms. > > > >3) One item that may also need some consideration is the > option to let the > > >requesting router give its preference to some values > (prefix length, > > >lifetimes, IAprefix-options contents (maybe?), the > prefixes). I'm not > > >sure of the usefulness of these, really. In the real > world, I think ISP's > > >set them, either to some values communicated off-band, or > otherwise. The > > >complexity required (policy, policy,...) when the > delegating router must > > >decide whether it can agree to the requested values seems > like a big hit. > > >I'm not really sure whether it's worth it, even though it > may offer some > > >flexibility for some corner cases. The only commonly used > one I could > > >think of would be whether the customer wants _single_ /64 > (for the only > > >one subnet!) or whole /48 -- seems like a heavy baggage for that. > > > > The cost of allowing the requesting router to express its > preferences > > isn't all that great - a simple delegating router can simply ignore > > the requesting router's preferences... > > Certainly. I see this as a potential problem from two directions: > > 1) delegating router handling untrusted input values, creating > delegations based on them, and > > 2) the requesting router requesting something that > architectually differs > *a lot* from what's given (example: /64's directly for its > interfaces, and > one /48 delegated). The same problem will occur, when the requesting router is expecting the /48 and the server ignoring its preference and just gives it /64. The solution would be, 1) when a site registers with ISP, preconfigure the topology of the site in the dhcpv6 server. Thus, it can provide the requesting router with necessary prefixes. 2) If the site topology is not known, configure dhcpv6 server with some dynamic pool which always provide a single /64 prefix for the IA_PD. Let the requesting router send as many as IA_PD it wants. But, here the concept of subnetting dies. If there is no preconfiguration, then the server wont be able to provide the preferred prefix of the requesting routers. This problem remains unsolved. Basically, the site which is connecting to ISP is authenticated, moreover, they pay for whatever service they use, i dont see that any harm in taking the preference from the requesting router and assign the prefix accordingly. > Then what? Can the requesting router > handle this > kind of situation? The problem is that entering preferences > *in-band* > (instead of out-of-band, as usual) seems problematic, as it creates > difficult situations at both ends in the cases the > preferences are not met > (and policy decisions even if met). > > At the very least, one should clarify something along the > lines of "In any > case, the requesting router MUST NOT depend on any of its > preferences to > be honored" if this feature is really necessary. I pay for my using the services provided by ISPs, why shouldn't my preferences be honoured? > > > > > option-code: OPTION_IA_PD (TBD) > > > > > > option-length: 12 + length of IA_PD-options field. > > > > > >==> is it necessary to say how the option-code is > stored/transported > > >(signed/unsigned) ? I guess this is clear enough? > > > > The format of the option code is (should be?) specified in the > > DHCPv6 spec. > > Ok -- it's just that AFAICS, I don't see that a connection > has been made > between the two (even if they use the same name). > > > > The requesting router MUST ignore any Advertise message > that includes > > > a Status Code option containing the value NoPrefixAvail, > > > > > >==> where is the defintion of NoPrefixAvail or other codes? > > > > Needs a pointer to the DHCPv6 spec? > > At the minimum. > > > > message for the user, a Server Identifier option with > the delegating > > > router's DUID and a Client Identifier option with the > requesting > > > router's DUID. > > > > > >==> DUID used for the first time (inherited from DHCPv6 > spec I think), > > >spell it out? > > > > Needs a pointer to the DHCPv6 spec? > > Yes please, and spell out the abbreviation in the text (no > need to put it > up in terminology IMO). > > > > When a requesting router subnets a delegated prefix, > it must assign > > > additional bits to the prefix to generate unique, > longer prefixes. > > > For example, if the requesting router in Figure 1 were > delegated > > > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > > > 3FFE:FFFF:0:2::/64 for assignment to the two links in > the subscriber > > > network. > > > > > >==> I'm not sure if the first sentence is entirely > accurate. One could > > >use prefix delegation to get multiple /64's directly from > your ISP, then > > >extra bits wouldn't be needed at all. > > > > But that wouldn't be "subnetting", I don't think - just > reassignment? > > Ah, got me there :-). The problem with the language seems to > be that even > though it says "when ... subnets", there are no other "whens" so this > paragraph is taken to imply all of it (especially since the > main form of > prefix delegation always includes subnetting, as noted earlier in the > draft). > > > >14. Security Considerations > > > > > >==> personally I'm rather worried about the requestor > being able to give > > >"guidance" to the delegator what on what it wants. > Unreliable input could > > >lead to bad results in an implementation which hasn't been > done carefully > > >(requesting link/site-local prefixes which don't exist, > effect of bogus > > >prefixlengths etc.etc.). [more of this was above] > > > > Paranoid delegating routers can simply ignore the guidance... > > Yep, put that in there :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 12:10:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PKAT7f021314; Tue, 25 Feb 2003 12:10:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PKATPE021313; Tue, 25 Feb 2003 12:10:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PKAM7f021306 for ; Tue, 25 Feb 2003 12:10:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PKAVVL021931 for ; Tue, 25 Feb 2003 12:10:31 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14754 for ; Tue, 25 Feb 2003 13:10:26 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 20:10:25 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Tue, 25 Feb 2003 20:08:44 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Tue, 25 Feb 2003 20:10:25 Z Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by relay11.sun.com with ESMTP; Tue, 25 Feb 2003 20:10:24 Z Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PKANYf016491; Tue, 25 Feb 2003 21:10:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 21:09:43 +0100 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF685@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mika Liljeberg'" Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com Subject: RE: a few comments on anycast mechanisms Date: Tue, 25 Feb 2003 21:09:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > TCP has the problem that it simply can't be used with an > anycast address > without changing the protocol or somehow handling the binding > transparently on L3 (as in MIPv6). UDP doesn't have this problem; at > most the applications need to be changed to react correctly to peer > address change. => But is this the only problem? I mean even if there is a way of making apps using UDP react correctly to address changes, is it not possible that some apps would want to make sure that they are still talking to the _same_peer_ and not just the same application on another host? > Some of the problems relate to figuring out what > constitutes a session > with a UDP application. => There was a reference made that the draft deals with stateful applications. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 25 12:35:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PKZb7f021794; Tue, 25 Feb 2003 12:35:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PKZabw021793; Tue, 25 Feb 2003 12:35:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PKZV7f021783 for ; Tue, 25 Feb 2003 12:35:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PKZeVL000231 for ; Tue, 25 Feb 2003 12:35:41 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25543 for ; Tue, 25 Feb 2003 13:35:33 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 20:34:52 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Tue, 25 Feb 2003 20:34:52 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Tue, 25 Feb 2003 20:34:52 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP; Tue, 25 Feb 2003 20:34:51 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1PKZ0aj021509; Tue, 25 Feb 2003 22:35:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1PKYvoR021506; Tue, 25 Feb 2003 22:34:57 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: a few comments on anycast mechanisms From: Mika Liljeberg To: "Hesham Soliman (EAB)" Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF685@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053807FEF685@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046205296.20906.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 22:34:56 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-02-25 at 22:09, Hesham Soliman (EAB) wrote: > => But is this the only problem? I mean even if there is > a way of making apps using UDP react correctly to address > changes, is it not possible that some apps would want to > make sure that they are still talking to the _same_peer_ > and not just the same application on another host? I expect so. That's what I meant when I was talking about authenticating the binding. Other applications might not care and might prefer a quick, if insecure, redirect instead. > => There was a reference made that the draft deals with > stateful applications. Indeed. How does one recognize a stateful application on L3? [Unless we require the application to indicate this explicitly.] MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 13:20:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLKQ7f022254; Tue, 25 Feb 2003 13:20:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PLKPDJ022253; Tue, 25 Feb 2003 13:20:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLKL7f022246 for ; Tue, 25 Feb 2003 13:20:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PLKUVK010985 for ; Tue, 25 Feb 2003 13:20:30 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08677 for ; Tue, 25 Feb 2003 13:20:25 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:20:19 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Tue, 25 Feb 2003 21:20:18 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Tue, 25 Feb 2003 21:20:18 Z Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by relay1.sun.com with ESMTP; Tue, 25 Feb 2003 21:20:17 Z Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PLK5Ye021793; Tue, 25 Feb 2003 22:20:05 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 22:20:05 +0100 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF689@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mika Liljeberg'" Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com Subject: RE: a few comments on anycast mechanisms Date: Tue, 25 Feb 2003 22:20:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Tue, 2003-02-25 at 22:09, Hesham Soliman (EAB) wrote: > > => But is this the only problem? I mean even if there is > > a way of making apps using UDP react correctly to address > > changes, is it not possible that some apps would want to > > make sure that they are still talking to the _same_peer_ > > and not just the same application on another host? > > I expect so. That's what I meant when I was talking about > authenticating > the binding. Other applications might not care and might > prefer a quick, > if insecure, redirect instead. => Right, but I guess the latter type of application would not be harmed by the "extra" security. > > > => There was a reference made that the draft deals with > > stateful applications. > > Indeed. How does one recognize a stateful application on > L3? [Unless we > require the application to indicate this explicitly.] => We don't need to recognise them, see my comment above. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 25 13:23:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLNE7f022267; Tue, 25 Feb 2003 13:23:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PLNEV6022266; Tue, 25 Feb 2003 13:23:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLN97f022259 for ; Tue, 25 Feb 2003 13:23:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PLNIVL015344 for ; Tue, 25 Feb 2003 13:23:19 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18755 for ; Tue, 25 Feb 2003 14:23:11 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:22:53 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Tue, 25 Feb 2003 21:22:52 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Tue, 25 Feb 2003 21:22:52 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP; Tue, 25 Feb 2003 21:22:51 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1PLNEaj021719; Tue, 25 Feb 2003 23:23:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1PLNCMQ021718; Tue, 25 Feb 2003 23:23:12 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: a few comments on anycast mechanisms From: Mika Liljeberg To: "Hesham Soliman (EAB)" Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF689@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053807FEF689@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1046208191.21507.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 23:23:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote: > => Right, but I guess the latter type of application > would not be harmed by the "extra" security. Performance? MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 13:26:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLQq7f022287; Tue, 25 Feb 2003 13:26:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PLQqmE022286; Tue, 25 Feb 2003 13:26:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLQl7f022279 for ; Tue, 25 Feb 2003 13:26:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PLQvVK013050 for ; Tue, 25 Feb 2003 13:26:57 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01870 for ; Tue, 25 Feb 2003 13:26:51 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:26:49 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP; Tue, 25 Feb 2003 21:26:49 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Tue, 25 Feb 2003 21:26:49 Z Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by relay2.sun.com with ESMTP; Tue, 25 Feb 2003 21:26:48 Z Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PLQknS012271; Tue, 25 Feb 2003 22:26:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 22:26:46 +0100 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF68A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mika Liljeberg'" Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com Subject: RE: a few comments on anycast mechanisms Date: Tue, 25 Feb 2003 22:26:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote: > > => Right, but I guess the latter type of application > > would not be harmed by the "extra" security. > > Performance? => In theory yes, but I don't know how significant it will be. I suppose we need to see a complete framework/solution before we can discuss the scenarios where performance will be a factor and how significant it will be. Hesham > > MikaL > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 13:31:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLVQ7f022582; Tue, 25 Feb 2003 13:31:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PLVQtW022581; Tue, 25 Feb 2003 13:31:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PLVK7f022561 for ; Tue, 25 Feb 2003 13:31:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PLVTVL018468 for ; Tue, 25 Feb 2003 13:31:29 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22811 for ; Tue, 25 Feb 2003 14:31:19 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:31:13 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:31:09 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:31:08 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 21:31:08 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1PLMLs31053; Tue, 25 Feb 2003 23:22:21 +0200 Date: Tue, 25 Feb 2003 23:22:20 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <002101c2dd07$6128d250$38e62a0f@nt23056> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: > > > The spec allows for flexibility in deployment scenarios by > > > allowing the ISP (through the delegating router) to control > > > the behavior of the requesting router, or by leaving the > > > behavior under the control of the requesting router > > > by setting T1 and T2 to 0 (see section 8 of the draft). > > > > Yes, I noticed they can be zero -- all I'm questioning is the > > usability of > > this flexibility. I fail to see why such flexibility is useful. The > > requesting router can be as flexible as it wants -- and > > refresh bindings > > when it deems it necessary even without guidance. > > On reading your previous mail, i thought you have agreed with T1 and T2 :-) Well, if it's DHCPv6 functionality, it's ok to keep some of those intact even if misguided.. :-) > Probably, the routers which are "wise" enough to rely up of prefixes > provided by the DHCPv6 server and "dumb" enough to trust the time > values provided by it, may need this ;-) Perhaps, these T1 and T2 values > exist from > DHCPv4 architecture itself and worked successfully. Well, the routers MUST have this code *anyway*, as they cannot be sure T1/T2 will always be provided, so I really see little use.. > > I don't see it overly restrictive myself: as an operator and end-user, > > if someone connects to two ISP's, it's (almost, at least) always done > > either from two separate routers (no use doing it from one, really), > > or in a serial fashion (terminate one, establish the other -- like > > dialup). > > Simultaneous connection is also needed in some cases, as i told > earlier, like, high availablity High availability to two ISP's from one router is a joke. > > Certainly. I see this as a potential problem from two directions: > > > > 1) delegating router handling untrusted input values, creating > > delegations based on them, and > > > > 2) the requesting router requesting something that > > architectually differs > > *a lot* from what's given (example: /64's directly for its > > interfaces, and > > one /48 delegated). > > The same problem will occur, when the requesting router is expecting > the /48 and the server ignoring its preference and just gives > it /64. Sure. (Or the same for different changes in prefix lengths.) > The solution would be, > 1) when a site registers with ISP, preconfigure the topology of the > site in the dhcpv6 server. Thus, it can provide the requesting > router with necessary prefixes. I think it is natural to be able to expect that the ISP configures this kind of stuff (one /64, multiple /64, /48 -- that's all they need!) out-of-band. As currently. I don't think there's any reason to expect otherwise. > 2) If the site topology is not known, configure dhcpv6 server > with some dynamic pool which always provide a single /64 prefix > for the IA_PD. Let the requesting router send as many as IA_PD > it wants. But, here the concept of subnetting dies. Very discourageable, IMO. > Basically, the site which is connecting to ISP is authenticated, > moreover, they pay for whatever service they use, i dont see > that any harm in taking the preference from the requesting > router and assign the prefix accordingly. You fail to understand the relationship between the ISP and the user. Whether they use /64, /48 or whatever is, and will typically be, pre-agreed when people sign up for the service. Communicated out-of-band. I don't think that typically the user is able to affect that decision (at prefix delegation time) at all. Of course, ISP's could change their models, but don't count on it.. > > Then what? Can the requesting router > > handle this > > kind of situation? The problem is that entering preferences > > *in-band* > > (instead of out-of-band, as usual) seems problematic, as it creates > > difficult situations at both ends in the cases the > > preferences are not met > > (and policy decisions even if met). > > > > At the very least, one should clarify something along the > > lines of "In any > > case, the requesting router MUST NOT depend on any of its > > preferences to > > be honored" if this feature is really necessary. > > I pay for my using the services provided by ISPs, why shouldn't > my preferences be honoured? ISP's will love you for spending 50$/mo for the premium service instead of 30$/mo, so -- maybe they'll let you say the preference. For the rest, it won't matter and it's configured out-of-band. Most agreements with ISP's are very draconian. The problems like these are not solved with specifications. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 14:09:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PM9m7f023437; Tue, 25 Feb 2003 14:09:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PM9lq5023436; Tue, 25 Feb 2003 14:09:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PM9i7f023429 for ; Tue, 25 Feb 2003 14:09:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PM9rVL000888 for ; Tue, 25 Feb 2003 14:09:53 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16334 for ; Tue, 25 Feb 2003 15:09:47 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:09:46 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:09:46 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:09:46 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:09:46 Z Subject: RE: Site-local clarification Date: Tue, 25 Feb 2003 14:09:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C40@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Site-local clarification Thread-Index: AcLc++SwDHslaWMHSf6p85qkvRUMLwAHVb2w From: "Michel Py" To: "Siva Veerepalli" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1PM9i7f023430 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Siva Veerepalli wrote: | [ARCH] Site-local addresses are designed to be used for | addressing inside of a site without the need for a global | prefix. Although a subnet ID may be up to 54-bits long, | it is expected that globally-connected sites will use the | same subnet IDs for site-local and global prefixes. > Does the interpretation of the above sentence mean, "if my > global prefix is 3FFE:2900:1107:314::/64, my site-local > prefix would be FECE:2900:1107:314::/64" ? No. Following the recommendations of RFC3177, if your global prefix is 3FFE:2900:1107:314::/64 and the same subnet also has a site-local address the site-local prefix would be FEC0:0:0:314::/64. 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 Tue Feb 25 14:42:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PMgJ7f023763; Tue, 25 Feb 2003 14:42:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1PMgInv023762; Tue, 25 Feb 2003 14:42:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1PMgF7f023755 for ; Tue, 25 Feb 2003 14:42:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1PMgOVL009316 for ; Tue, 25 Feb 2003 14:42:24 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07648 for ; Tue, 25 Feb 2003 15:42:18 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:42:16 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:42:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:42:15 Z Received: from pianosa.catch22.org (pianosa.catch22.org [66.93.182.229]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 22:42:15 Z Received: by pianosa.catch22.org (Postfix, from userid 1000) id 8225660; Tue, 25 Feb 2003 14:42:13 -0800 (PST) Date: Tue, 25 Feb 2003 16:42:13 -0600 From: David Terrell To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Message-Id: <20030225224213.GA19540@pianosa.catch22.org> Reply-To: David Terrell References: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045910906.26677.29.camel@devil> User-Agent: Mutt/1.4i 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: 4:40PM up 9 days, 20:07, 42 users, load averages: 0.90, 0.72, 0.72 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Feb 22, 2003 at 12:48:27PM +0200, Mika Liljeberg wrote: > Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format > if necessary. Just add some text explaining this. With our hybrid > IPv4/IPv6 stack implementation this would work out of the box. Did I miss some announcement that mapped addresses were suddenly allowed to be present on the wire? They were supposed to be only used in the socket API. Camels... tents.... -- David Terrell | "War is peace, Prime Minister, Nebcorp | freedom is slavery, dbt@meat.net | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean." - Chris Fester -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 16:01:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q01S7f024666; Tue, 25 Feb 2003 16:01:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q01SEo024665; Tue, 25 Feb 2003 16:01:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q01O7f024658 for ; Tue, 25 Feb 2003 16:01:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q01XVK001928 for ; Tue, 25 Feb 2003 16:01:33 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05977 for ; Tue, 25 Feb 2003 16:01:28 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:01:28 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:01:27 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:01:27 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:01:27 Z 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 QAA18154 for ; Tue, 25 Feb 2003 16:01:26 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1Q01Pf15674; Tue, 25 Feb 2003 16:01:25 -0800 X-mProtect: <200302260001> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpqylTJ; Tue, 25 Feb 2003 16:01:23 PST Message-Id: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 16:01:09 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Follow up to IAB response to Robert Elz's Appeal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard [1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? Bob Hinden, Margaret Wasserman; IPv6 Chairs Thomas Narten, Erik Nordmark; Internet ADs [1] IAB, "Re: Appeal against IESG decision", http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 16:27:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0Ra7f025429; Tue, 25 Feb 2003 16:27:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q0RZ5q025428; Tue, 25 Feb 2003 16:27:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0RW7f025421 for ; Tue, 25 Feb 2003 16:27:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q0RfVK010729 for ; Tue, 25 Feb 2003 16:27:41 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19702 for ; Tue, 25 Feb 2003 17:27:35 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:25:20 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:23:37 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:25:19 Z Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:25:18 Z Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1Q0PHYe003451; Wed, 26 Feb 2003 01:25:17 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 01:25:16 +0100 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF690@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: RE: Follow up to IAB response to Robert Elz's Appeal Date: Wed, 26 Feb 2003 01:25:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Sounds like a good approach. Hesham > -----Original Message----- > From: Bob Hinden [mailto:hinden@iprg.nokia.com] > Sent: Wednesday, February 26, 2003 1:01 AM > To: ipng@sunroof.eng.sun.com > Subject: Follow up to IAB response to Robert Elz's Appeal > > > > The IAB has responded to an appeal from Robert Elz of the > IESG decision > to approve the IPv6 Addressing Architecture > (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that > the document > should not be published as a Draft Standard [1]. Given > that the revised > document is a significant improvement over RFC 2473, and > that RFC2473 is > badly out of date, we believe it is desirable to go ahead > and publish the > document as a Proposed Standard at this time ASAP in order to get a > replacement to RFC2473 out. > > In parallel, it would be appropriate to discuss the details > of the IAB > response and how the WG wishes to respond to the IAB > recommendations. Note > that approving the document as PS at this time does not > imply that the WG > agrees with all of the IAB's recommendations nor does it > preclude any > particular follow-on action by the WG or IESG. However, > approval at PS is > something that can be done relatively quickly. > > Does this approach make sense to the WG? > > Bob Hinden, Margaret Wasserman; IPv6 Chairs > Thomas Narten, Erik Nordmark; Internet ADs > > [1] IAB, "Re: Appeal against IESG decision", > http://www.iab.org/Appeals/kre-ipng-address-arch-draft-stand ard-response.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 25 16:30:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0Un7f025445; Tue, 25 Feb 2003 16:30:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q0UnrX025444; Tue, 25 Feb 2003 16:30:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0Ui7f025437 for ; Tue, 25 Feb 2003 16:30:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q0UrVK011718 for ; Tue, 25 Feb 2003 16:30:54 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10830 for ; Tue, 25 Feb 2003 17:30:48 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAW00G6543CXU@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 17:30:48 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAW00M7U43BET@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 25 Feb 2003 17:30:48 -0700 (MST) Date: Tue, 25 Feb 2003 16:30:47 -0800 From: Alain Durand Subject: Re: Follow up to IAB response to Robert Elz's Appeal To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Message-id: <3E5C0AB7.4080107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > > The IAB has responded to an appeal from Robert Elz of the IESG decision > to approve the IPv6 Addressing Architecture > (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the > document should not be published as a Draft Standard [1]. Given that > the revised document is a significant improvement over RFC 2473, and > that RFC2473 is badly out of date, we believe it is desirable to go > ahead and publish the document as a Proposed Standard at this time > ASAP in order to get a replacement to RFC2473 out. > > In parallel, it would be appropriate to discuss the details of the IAB > response and how the WG wishes to respond to the IAB recommendations. > Note that approving the document as PS at this time does not imply > that the WG agrees with all of the IAB's recommendations nor does it > preclude any particular follow-on action by the WG or IESG. However, > approval at PS is something that can be done relatively quickly. > > Does this approach make sense to the WG? sounds to me like a sensible course of action. - 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 25 16:40:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0eM7f025735; Tue, 25 Feb 2003 16:40:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q0eM4B025734; Tue, 25 Feb 2003 16:40:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q0eI7f025724 for ; Tue, 25 Feb 2003 16:40:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q0eRVL019374 for ; Tue, 25 Feb 2003 16:40:27 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27051 for ; Tue, 25 Feb 2003 17:40:22 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:39:03 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:39:03 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:39:03 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 00:39:03 Z Subject: RE: Follow up to IAB response to Robert Elz's Appeal Date: Tue, 25 Feb 2003 16:39:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <963621801C6D3E4A9CF454A1972AE8F5BA6F@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Follow up to IAB response to Robert Elz's Appeal Thread-Index: AcLdK1wiUE/BWfpCT92YxMi8vvTpMwAA86/Q From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1Q0eJ7f025725 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob Hinden wrote: > The IAB has responded to an appeal from Robert Elz of the > IESG decision to approve the IPv6 Addressing Architecture > (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that > the document should not be published as a Draft Standard[1]. > Given that the revised document is a significant improvement > over RFC 2473, and that RFC2473 is badly out of date, Agree. > we believe it is desirable to go ahead and publish the > document as a Proposed Standard at this time ASAP in order > to get a replacement to RFC2473 out. > In parallel, it would be appropriate to discuss the details > of the IAB response and how the WG wishes to respond to the > IAB recommendations. Note that approving the document as PS > at this time does not imply that the WG agrees with all of > the IAB's recommendations nor does it preclude any particular > follow-on action by the WG or IESG. However, approval at PS > is something that can be done relatively quickly. > Does this approach make sense to the WG? Does 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 25 17:36:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q1aH7f026184; Tue, 25 Feb 2003 17:36:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q1aHBA026183; Tue, 25 Feb 2003 17:36:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q1aD7f026176 for ; Tue, 25 Feb 2003 17:36:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q1aMVK001016 for ; Tue, 25 Feb 2003 17:36:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25880 for ; Tue, 25 Feb 2003 18:36:17 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:36:14 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:32:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:32:33 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:32:33 Z Received: from consulintel02 ([220.128.56.110]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Wed, 26 Feb 2003 02:34:24 +0100 Message-Id: <02dd01c2dd37$291e0c10$6e3880dc@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> Subject: Re: Follow up to IAB response to Robert Elz's Appeal Date: Wed, 26 Feb 2003 09:34:03 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 220.128.56.110 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This approach is ok to me. Regards, Jordi ----- Original Message ----- From: "Bob Hinden" To: Sent: Wednesday, February 26, 2003 8:01 AM Subject: Follow up to IAB response to Robert Elz's Appeal > > The IAB has responded to an appeal from Robert Elz of the IESG decision > to approve the IPv6 Addressing Architecture > (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document > should not be published as a Draft Standard [1]. Given that the revised > document is a significant improvement over RFC 2473, and that RFC2473 is > badly out of date, we believe it is desirable to go ahead and publish the > document as a Proposed Standard at this time ASAP in order to get a > replacement to RFC2473 out. > > In parallel, it would be appropriate to discuss the details of the IAB > response and how the WG wishes to respond to the IAB recommendations. Note > that approving the document as PS at this time does not imply that the WG > agrees with all of the IAB's recommendations nor does it preclude any > particular follow-on action by the WG or IESG. However, approval at PS is > something that can be done relatively quickly. > > Does this approach make sense to the WG? > > Bob Hinden, Margaret Wasserman; IPv6 Chairs > Thomas Narten, Erik Nordmark; Internet ADs > > [1] IAB, "Re: Appeal against IESG decision", > http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 17:58:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q1vx7f026590; Tue, 25 Feb 2003 17:57:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q1vxP0026589; Tue, 25 Feb 2003 17:57:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q1vt7f026582 for ; Tue, 25 Feb 2003 17:57:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q1w4VK006901 for ; Tue, 25 Feb 2003 17:58:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08196 for ; Tue, 25 Feb 2003 18:57:57 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:57:44 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:57:07 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:57:07 Z Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 01:57:07 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1Q1uu6N016139; Tue, 25 Feb 2003 17:56:57 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA18783; Wed, 26 Feb 2003 01:56:56 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org, Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt From: Ole Troan Date: Wed, 26 Feb 2003 01:56:56 +0000 In-Reply-To: (Pekka Savola's message of "Sat, 22 Feb 2003 22:57:10 +0200 (EET)") Message-Id: <7t5vfz7yfbr.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > reasons why it wouldn't be just enough to have only one IA_PD per > requesting router? (The option to and subsequent complexity of) > generating one for each interface seems like a completely unnecessary > feature to me -- it's the router which should be doing prefix delegation > to it's downstream interfaces! let me pick this one up from the start. the reasons for allowing multiple IA_PDs are: - consistency with address assignment as you can use multiple IA_NAs - future-proofing. in the ISP/user scenario I do see little need for multiple IA_PDs. if PD is used within an administrative domain assigning prefixes to downstream interfaces may make more sense it does add some complexity, and I think we've made it pretty clear in the draft that the typical usage will be to use one IA_PD. we just didn't want to close the door on possible future uses of the protocol. /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 25 22:34:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q6YA7f027758; Tue, 25 Feb 2003 22:34:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q6YA7e027757; Tue, 25 Feb 2003 22:34:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q6Y77f027749 for ; Tue, 25 Feb 2003 22:34:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q6YGVK007696 for ; Tue, 25 Feb 2003 22:34:16 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26487 for ; Tue, 25 Feb 2003 23:34:11 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 06:34:10 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 06:34:10 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 06:34:09 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 06:34:09 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1Q6Xt201278; Wed, 26 Feb 2003 08:33:55 +0200 Date: Wed, 26 Feb 2003 08:33:55 +0200 (EET) From: Pekka Savola To: Ole Troan cc: Ralph Droms , , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <7t5vfz7yfbr.fsf@mrwint.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Feb 2003, Ole Troan wrote: > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > reasons why it wouldn't be just enough to have only one IA_PD per > > requesting router? (The option to and subsequent complexity of) > > generating one for each interface seems like a completely unnecessary > > feature to me -- it's the router which should be doing prefix delegation > > to it's downstream interfaces! > > let me pick this one up from the start. > the reasons for allowing multiple IA_PDs are: > > - consistency with address assignment as you can use multiple IA_NAs > - future-proofing. in the ISP/user scenario I do see little need for > multiple IA_PDs. if PD is used within an administrative domain > assigning prefixes to downstream interfaces may make more sense My take on this is is that "we don't need that yet, so why add it yet"; leaving the "base prefix delegation spec" extendable (e.g. define multiple IA_PD's in a later document) would be just fine. > it does add some complexity, and I think we've made it pretty clear in > the draft that the typical usage will be to use one IA_PD. we just > didn't want to close the door on possible future uses of the protocol. IMO, it wasn't as clear as that. I can live with this, but I can't help wondering why the base spec has to cover even all the theoretical cases. I'd much rather see a very simple basic version of prefix delegation which can be used to get started. There's no way we could anticipate what will be needed in 3-5 years and we could further define the extensions when they're needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 25 23:55:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q7tJ7f028449; Tue, 25 Feb 2003 23:55:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q7tJ7J028448; Tue, 25 Feb 2003 23:55:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q7tE7f028441 for ; Tue, 25 Feb 2003 23:55:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q7tOVL018951 for ; Tue, 25 Feb 2003 23:55:24 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15208 for ; Wed, 26 Feb 2003 00:55:17 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 07:55:01 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 07:53:19 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 07:55:01 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 07:55:00 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6741315215; Wed, 26 Feb 2003 16:55:15 +0900 (JST) Date: Wed, 26 Feb 2003 16:55:12 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 65 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 24 Feb 2003 08:00:00 -0500, >>>>> Ralph Droms said: > Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and > reply with comments. If you recommend the document for advancement without > revision, please respond with a quick acknowledgment. No response will be > interpreted as a lack of support for advancing the document. I've finally reviewed the latest draft. As I said before, I basically support the document. However, I don't think the current revision is ready to be published. IMO, it is still incomplete and has not fully addressed open issues. Detailed comments follow: 1. Issues about the preferred and valid lifetimes were not fully addressed. I've not seen consensus on this in the dhc-wg ML. Please re-check the thread entitled "PD lifetimes" that started on Thu, 23 Jan 2003 19:18:57 +0900. 2. Section 11.1 now specifies the requesting router to use Rebind/Reply exchanges to verify an existing binding (instead of Renew/Reply exchanges). According to the very recent clarifications on the base DHCPv6 spec, however, I'm not sure if Rebind is appropriate here; the server should drop the Rebind message unless it has an explicit knowledge about the validity or invalidity of the prefix, which should not be the case (e.g.) when the upstream link flaps. 3. Section 10.2 contains the following sentence (newly added in the latest revision): If the delegating router cannot delegate any prefixes to an IA_PD in the message from the requesting router, the delegating router MUST include the IA_PD in the Reply message with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail. I guess the "Reply" should be "Advertisement" here, because this section is talking about "Delegating Router Solicitation." I also guess the sentence was added in response to a question of mine in the ML. If so, a similar clarification should be introduced to Section 11.2 as well. Additionally, the corresponding client behaviors should also be documented. 4. The PD draft should reflect some parts of draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. We may be able to omit some of them as trivial clarifications, but we should reflect some other part of them because the base DHCPv6 spec (and thus the clarifications for it) is too specific to address assignment. In some cases, implementors can use analogy of the base spec to implement the PD draft, but we should basically provide comprehensive information in the PD draft itself to ensure better interoperability. (As some people, including me, have repeatedly pointed out, the best approach would be to make the base spec generic so that each stateful method can just refer to the base spec. Since we could not make it due to the "it's too late" reason, we should be responsible to implementors for providing detailed information within the PD specification). 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 26 00:05:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8577f028559; Wed, 26 Feb 2003 00:05:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q856Jr028558; Wed, 26 Feb 2003 00:05:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8537f028551 for ; Wed, 26 Feb 2003 00:05:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q85CVK023346 for ; Wed, 26 Feb 2003 00:05:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03204 for ; Wed, 26 Feb 2003 01:05:07 -0700 (MST) From: juha.wiljakka@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:05:07 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:05:06 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:05:06 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:05:06 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1Q88Cm07260 for ; Wed, 26 Feb 2003 10:08:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Feb 2003 10:05:04 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 10:05:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Follow up to IAB response to Robert Elz's Appeal Date: Wed, 26 Feb 2003 10:05:04 +0200 Message-Id: <245DBCAEEC4F074CB77B3F984FF9834F01906E8F@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up to IAB response to Robert Elz's Appeal Thread-Index: AcLdK1wiUE/BWfpCT92YxMi8vvTpMwAA86/QAA+LotA= To: , X-OriginalArrivalTime: 26 Feb 2003 08:05:04.0769 (UTC) FILETIME=[C5188F10:01C2DD6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1Q8537f028552 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, makes sense also to me. BR, -Juha W.- -----Original Message----- From: ext Michel Py [mailto:michel@arneill-py.sacramento.ca.us] Sent: 26 February, 2003 02:39 > we believe it is desirable to go ahead and publish the > document as a Proposed Standard at this time ASAP in order > to get a replacement to RFC2473 out. > In parallel, it would be appropriate to discuss the details > of the IAB response and how the WG wishes to respond to the > IAB recommendations. Note that approving the document as PS > at this time does not imply that the WG agrees with all of > the IAB's recommendations nor does it preclude any particular > follow-on action by the WG or IESG. However, approval at PS > is something that can be done relatively quickly. > Does this approach make sense to the WG? Does 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 26 00:24:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8OO7f029068; Wed, 26 Feb 2003 00:24:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q8OOVX029067; Wed, 26 Feb 2003 00:24:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8OK7f029060 for ; Wed, 26 Feb 2003 00:24:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q8OUVL024089 for ; Wed, 26 Feb 2003 00:24:30 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01368 for ; Wed, 26 Feb 2003 01:24:24 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:23 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:22 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:22 Z Received: from dhcp-168-17-124.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:21 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1Q8P3if007584; Wed, 26 Feb 2003 09:25:06 +0100 (CET) Date: Wed, 26 Feb 2003 09:25:02 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Iljitsch van Beijnum" , "Pekka Savola" , "Alan E. Beard" , "Tim Chown" , , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Kurt Erik Lindqvist wrote: >> This I thought was more or less standard. I was talking about >> less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. > Actually not. Go look at the presentations from the San Diego IETF. I think it was in the ISIS-WG. It was based on 'heartbeats' being sent and you know that if you have missed X number of packets in Y time the link is down. Don't remember all the details. I think it also included moving to partial SPF calculations to get this down even further. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 00:24:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8Oc7f029078; Wed, 26 Feb 2003 00:24:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1Q8Oc6v029077; Wed, 26 Feb 2003 00:24:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1Q8OX7f029070 for ; Wed, 26 Feb 2003 00:24:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1Q8OhVL024127 for ; Wed, 26 Feb 2003 00:24:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18148 for ; Wed, 26 Feb 2003 00:24:37 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:37 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:36 Z Received: from dhcp-168-17-124.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 08:24:36 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1Q8Pjif008058; Wed, 26 Feb 2003 09:25:46 +0100 (CET) Date: Wed, 26 Feb 2003 09:25:44 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Iljitsch van Beijnum , "Alan E. Beard" , Tim Chown , , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Kurt Erik Lindqvist wrote: >>> This I thought was more or less standard. I was talking about >>> less than 100ms convergence. >> >> Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 >> ms rtt. You might need to talk to a guy named Albert Einstein; he >> wrote >> interesting RFCs about the speed of light that, as far as I know, have >> not been debunked yet. > > When multi-connecting, such RTT's seem reasonable. > > If you need to converge on the global routing table, that's a > non-starter > of course -- but that's one of the main strengths of multi-connecting. > No > changes to those outside of the ISP. > The original comment I made was on IGP though... - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 02:58:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QAwO7f000265; Wed, 26 Feb 2003 02:58:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1QAwOei000264; Wed, 26 Feb 2003 02:58:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QAwK7f000257 for ; Wed, 26 Feb 2003 02:58:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1QAwUVL019677 for ; Wed, 26 Feb 2003 02:58:30 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27288 for ; Wed, 26 Feb 2003 03:58:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 10:58:20 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 10:56:37 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 10:58:19 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 10:58:18 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1QAwBO29306; Wed, 26 Feb 2003 17:58:12 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1QAvxo08160; Wed, 26 Feb 2003 17:58:00 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Follow up to IAB response to Robert Elz's Appeal In-Reply-To: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Feb 2003 17:57:59 +0700 Message-Id: <8158.1046257079@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 25 Feb 2003 16:01:09 -0800 From: Bob Hinden Message-ID: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> | Does this approach make sense to the WG? For what it's worth, that's fine by me as well (and this also doesn't mean that I agree with all of the IAB's decision/recommendations either). kre ps: I have had no time to follow this WG for the past 3-4 months (since the end of last Oct), I'm a long way behind in my reading here, I just happened to notice this thread. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 06:12:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QECg7f001583; Wed, 26 Feb 2003 06:12:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1QECfF1001582; Wed, 26 Feb 2003 06:12:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QECa7f001572 for ; Wed, 26 Feb 2003 06:12:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1QECiVL019547 for ; Wed, 26 Feb 2003 06:12:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01430 for ; Wed, 26 Feb 2003 07:12:37 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 14:12:36 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 14:12:35 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 14:12:35 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 14:12:34 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QECQb0098734; Wed, 26 Feb 2003 15:12:26 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QECQG2011802; Wed, 26 Feb 2003 15:12:26 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40690 from ; Wed, 26 Feb 2003 15:12:24 +0100 Message-Id: <3E5CCB12.D19F59C6@hursley.ibm.com> Date: Wed, 26 Feb 2003 15:11:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Follow up to IAB response to Robert Elz's Appeal References: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, do it. Maybe get an IABer to the WG meeting to explain. Brian Bob Hinden wrote: > > The IAB has responded to an appeal from Robert Elz of the IESG decision > to approve the IPv6 Addressing Architecture > (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document > should not be published as a Draft Standard [1]. Given that the revised > document is a significant improvement over RFC 2473, and that RFC2473 is > badly out of date, we believe it is desirable to go ahead and publish the > document as a Proposed Standard at this time ASAP in order to get a > replacement to RFC2473 out. > > In parallel, it would be appropriate to discuss the details of the IAB > response and how the WG wishes to respond to the IAB recommendations. Note > that approving the document as PS at this time does not imply that the WG > agrees with all of the IAB's recommendations nor does it preclude any > particular follow-on action by the WG or IESG. However, approval at PS is > something that can be done relatively quickly. > > Does this approach make sense to the WG? > > Bob Hinden, Margaret Wasserman; IPv6 Chairs > Thomas Narten, Erik Nordmark; Internet ADs > > [1] IAB, "Re: Appeal against IESG decision", > http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 10:05:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QI5v7f005715; Wed, 26 Feb 2003 10:05:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1QI5vnR005714; Wed, 26 Feb 2003 10:05:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1QI5q7f005707 for ; Wed, 26 Feb 2003 10:05:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1QI61VK003297 for ; Wed, 26 Feb 2003 10:06:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02883 for ; Wed, 26 Feb 2003 11:05:55 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 18:05:55 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 18:04:11 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 18:05:54 Z Received: from halt-in.cisco.com (halt-in.cisco.com [171.70.144.185]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 18:05:54 Z Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 26 Feb 2003 10:05:50 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1QI4DCX021241 for ; Wed, 26 Feb 2003 19:04:13 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA08901 for ipng@sunroof.eng.sun.com; Wed, 26 Feb 2003 18:05:51 GMT Date: Wed, 26 Feb 2003 18:05:51 +0000 From: Derek Fawcus To: ipng@sunroof.eng.sun.com Subject: Re: Follow up to IAB response to Robert Elz's Appeal Message-Id: <20030226180551.E2350@edinburgh.cisco.com> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.2.20030225160022.026eeba0@mailhost.iprg.nokia.com>; from hinden@iprg.nokia.com on Tue, Feb 25, 2003 at 04:01:09PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Feb 25, 2003 at 04:01:09PM -0800, Bob Hinden wrote: > > The IAB has responded to an appeal from Robert Elz of the IESG decision > However, approval at PS is > something that can be done relatively quickly. > > Does this approach make sense to the WG? yeah - get it to at least PS. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 26 16:26:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R0QU7f007432; Wed, 26 Feb 2003 16:26:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1R0QUhp007431; Wed, 26 Feb 2003 16:26:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R0QQ7f007424 for ; Wed, 26 Feb 2003 16:26:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1R0QZVK016933 for ; Wed, 26 Feb 2003 16:26:35 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15205 for ; Wed, 26 Feb 2003 16:26:29 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 00:26:29 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 00:26:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 00:26:28 Z Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 00:26:28 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1R0PwHK025885; Wed, 26 Feb 2003 16:25:59 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA26668; Thu, 27 Feb 2003 00:26:16 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Ralph Droms , , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt From: Ole Troan Date: Thu, 27 Feb 2003 00:26:16 +0000 In-Reply-To: (Pekka Savola's message of "Wed, 26 Feb 2003 08:33:55 +0200 (EET)") Message-Id: <7t5znoiwouv.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, >> > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid >> > reasons why it wouldn't be just enough to have only one IA_PD per >> > requesting router? (The option to and subsequent complexity of) >> > generating one for each interface seems like a completely unnecessary >> > feature to me -- it's the router which should be doing prefix delegation >> > to it's downstream interfaces! >> >> let me pick this one up from the start. >> the reasons for allowing multiple IA_PDs are: >> >> - consistency with address assignment as you can use multiple IA_NAs >> - future-proofing. in the ISP/user scenario I do see little need for >> multiple IA_PDs. if PD is used within an administrative domain >> assigning prefixes to downstream interfaces may make more sense > > My take on this is is that "we don't need that yet, so why add it yet"; > leaving the "base prefix delegation spec" extendable (e.g. define multiple > IA_PD's in a later document) would be just fine. > >> it does add some complexity, and I think we've made it pretty clear in >> the draft that the typical usage will be to use one IA_PD. we just >> didn't want to close the door on possible future uses of the protocol. > > IMO, it wasn't as clear as that. > > I can live with this, but I can't help wondering why the base spec has to > cover even all the theoretical cases. I'd much rather see a very simple > basic version of prefix delegation which can be used to get started. > There's no way we could anticipate what will be needed in 3-5 years and we > could further define the extensions when they're needed. well, I have to disagree with you there. keeping PD consistent with other DHCP options makes for an easier understanding of how it works and for a simpler implementation. the fundamental idea behind using DHCP for PD is to re-use the existing DHCP infrastructure including option semantics. Distilled into one line: "Prefix Delegation with DHCP is done in exactly the same way as address assignment with DHCP is". /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 26 17:23:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R1NS7f007863; Wed, 26 Feb 2003 17:23:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1R1NSU7007862; Wed, 26 Feb 2003 17:23:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R1NO7f007855 for ; Wed, 26 Feb 2003 17:23:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1R1NWVL021125 for ; Wed, 26 Feb 2003 17:23:32 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00175 for ; Wed, 26 Feb 2003 18:23:27 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 01:23:03 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 01:21:18 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 01:23:02 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 01:23:02 Z Subject: RE: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" Date: Wed, 26 Feb 2003 17:23:00 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5BA84@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" Thread-Index: AcLZwUMl5uLNP6kZRMar/ijBv8nXYgEPSqLQ Content-class: urn:content-classes:message From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 To: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1R1NP7f007856 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this doc should move forward. One could call it RFC1219 for IPv6, this is something that lots of operators should be doing and don't. I don't see any reasons not to move forward. Michel. -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Friday, February 21, 2003 7:43 AM To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block" Hi All, During the last call period for "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block", there was only one comment (attached). The comment did not raise any specific technical issues with the document, but it did question its usefulness. As I am sure many of you know, documents should only be forwarded to the IESG for approval when there is a consensus of the WG that the document is both technically sound and useful. One ambivalent comment is not sufficient input to demonstrate WG consensus for publishing this document. So, if there are people in the WG who do believe that this document is both technically sound and useful and should be sent to the IESG for publication as an Informational RFC, could you please speak up? You can find the latest version of the document at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.t xt Thanks, Margaret >To: Bob Hinden & Margaret Wasserman >cc: ipng@sunroof.eng.sun.com >Subject: Re: IPv6 w.g. Last Call on "A Flexible Method for Managing the > Assignment of Bytes of an IPv6 Address Block" > > >On Thu, 16 Jan 2003, Bob Hinden & Margaret Wasserman wrote: > > This is a IPv6 working group last call for comments on advancing the > > following document as an Informational RFC: > > > > Title : A Flexible Method for Managing the Assignment of > > Bits of an IPv6 Address Block > > Author(s) : M. Blanchet > > Filename : draft-ietf-ipv6-ipaddressassign-06.txt > > Pages : 8 > > Date : 2003-1-6 > > >I don't have problems with this, though I'm not sure how useful this is >for most (but for some, certainly). > > >A point I've raised in the past is, most operators are not really >interested in optimizing the address assignments on a bit level (provided >that the number of customers is not so high it would be required). >Rather, here we do so with nibbles. Those are easier to calculate in the >head and work better with reverse DNS delegations too. > > >But I'm not sure whether this kind of "coarser approach for flexible >assignment" calls for some text or not. A mention at most, I think. >What do others feel? > > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 26 23:43:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R7hA7f009007; Wed, 26 Feb 2003 23:43:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1R7hAEq009006; Wed, 26 Feb 2003 23:43:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R7h77f008999 for ; Wed, 26 Feb 2003 23:43:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1R7hFVL003978 for ; Wed, 26 Feb 2003 23:43:15 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01696 for ; Thu, 27 Feb 2003 00:43:10 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 07:36:09 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 07:34:24 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 07:36:09 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 07:36:09 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1R7Zq610310; Thu, 27 Feb 2003 09:35:52 +0200 Date: Thu, 27 Feb 2003 09:35:52 +0200 (EET) From: Pekka Savola To: Ole Troan cc: Ralph Droms , , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <7t5znoiwouv.fsf@mrwint.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Feb 2003, Ole Troan wrote: > > cover even all the theoretical cases. I'd much rather see a very simple > > basic version of prefix delegation which can be used to get started. > > There's no way we could anticipate what will be needed in 3-5 years and we > > could further define the extensions when they're needed. > > well, I have to disagree with you there. keeping PD consistent with > other DHCP options makes for an easier understanding of how it works > and for a simpler implementation. the fundamental idea behind using > DHCP for PD is to re-use the existing DHCP infrastructure including > option semantics. Distilled into one line: "Prefix Delegation with > DHCP is done in exactly the same way as address assignment with DHCP is". I can live with that. I hear many (two sets of groups) are implementing DHCPv6 either for: - configuration parameters - prefix delegation (for the lack of alternatives) If you don't want address assignment in DHCP, doing it the same way in PD may seem like a burden. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 01:48:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R9mO7f009526; Thu, 27 Feb 2003 01:48:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1R9mOr6009525; Thu, 27 Feb 2003 01:48:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1R9mL7f009518 for ; Thu, 27 Feb 2003 01:48:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1R9mQVL024035 for ; Thu, 27 Feb 2003 01:48:26 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27572 for ; Thu, 27 Feb 2003 02:48:13 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 09:48:11 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 09:48:11 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 09:48:10 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 09:48:10 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA07406; Thu, 27 Feb 2003 09:47:55 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA25517; Thu, 27 Feb 2003 09:47:55 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1R9ltw01797; Thu, 27 Feb 2003 09:47:55 GMT Date: Thu, 27 Feb 2003 09:47:54 +0000 From: Tim Chown To: Pekka Savola Cc: Ole Troan , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Message-Id: <20030227094754.GB1648@login.ecs.soton.ac.uk> Mail-Followup-To: Pekka Savola , Ole Troan , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com References: <7t5znoiwouv.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Feb 27, 2003 at 09:35:52AM +0200, Pekka Savola wrote: > > I hear many (two sets of groups) are implementing DHCPv6 either for: > - configuration parameters > - prefix delegation (for the lack of alternatives) I would just add a "flag wave" for 6NET's Deliverable D3.2.3 which reports on DHCPv6 implementations which may be of interest to people here [apologies if a pointer has already been posted - just dipping in :] 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 27 08:43:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RGh87f011985; Thu, 27 Feb 2003 08:43:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RGh85Q011984; Thu, 27 Feb 2003 08:43:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RGh47f011977 for ; Thu, 27 Feb 2003 08:43:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RGhCVK014228 for ; Thu, 27 Feb 2003 08:43:12 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17817 for ; Thu, 27 Feb 2003 09:43:06 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 16:43:05 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 16:42:53 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 16:42:53 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 16:42:53 Z 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 IAA11187; Thu, 27 Feb 2003 08:42:46 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1RGgg216793; Thu, 27 Feb 2003 08:42:42 -0800 X-mProtect: <200302271642> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.164, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDtzHWa; Thu, 27 Feb 2003 08:42:40 PST Message-Id: <4.3.2.7.2.20030227081526.0230ce08@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 08:36:33 -0800 To: Erik.Nordmark@Sun.COM, Thomas Narten From: Bob Hinden & Margaret Wasserman Subject: Request to Advance "Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block Author(s) : M. Blanchet Filename : draft-ietf-ipv6-ipaddressassign-06.txt Pages : 8 Date : 2003-1-6 A working group last call for this document was completed on January 30, 2003. Bob Hinden / Margaret Wasserman 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 27 11:23:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RJNN7f012592; Thu, 27 Feb 2003 11:23:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RJNMlV012591; Thu, 27 Feb 2003 11:23:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RJNJ7f012584 for ; Thu, 27 Feb 2003 11:23:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RJNRVL004012 for ; Thu, 27 Feb 2003 11:23:27 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18661 for ; Thu, 27 Feb 2003 12:23:21 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:23:21 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:21:34 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:23:20 Z Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:23:20 Z Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RJN9YE026590 for ; Thu, 27 Feb 2003 11:23:09 -0800 (PST) Received: from SIVAV.qualcomm.com (sivav.qualcomm.com [129.46.222.34]) by magus.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RJN79A027986 for ; Thu, 27 Feb 2003 11:23:08 -0800 (PST) Message-Id: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 11:23:07 -0800 To: ipng@sunroof.eng.sun.com From: Siva Veerepalli Subject: Question on MLD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC2710 (MLD) states that when a General Membership Query is received, a node listening to the query sends a membership report for all multicast addresses it is listening to, excluding the all-nodes link-local multicast address and any multicast addresses of scope 0 (reserved) and 1 (node-local). My question is, is the node required to send the membership report for solicited-node multicast address as well? In general, since nodes do not receive link-local scope multicast packets from out side the link, why is it required for the nodes to report membership to the router for *any* link-local scope multicast addresses? Thanks, Siva -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 11:34:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RJYh7f012869; Thu, 27 Feb 2003 11:34:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RJYhRq012868; Thu, 27 Feb 2003 11:34:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RJYd7f012861 for ; Thu, 27 Feb 2003 11:34:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RJYlVL008165 for ; Thu, 27 Feb 2003 11:34:47 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29803 for ; Thu, 27 Feb 2003 12:34:40 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:34:39 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:34:38 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:34:38 Z Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:34:38 Z Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h1RJXPi6019104; Thu, 27 Feb 2003 14:33:25 -0500 (EST) Received: from nc.rr.com ([66.26.252.32]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Feb 2003 14:35:47 -0500 Message-Id: <3E5E67BE.3040201@nc.rr.com> Date: Thu, 27 Feb 2003 14:32:14 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Siva Veerepalli CC: ipng@sunroof.eng.sun.com Subject: Re: Question on MLD References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk MLD-snooping switches is the biggest reason. Brian Siva Veerepalli wrote: > RFC2710 (MLD) states that when a General Membership Query is received, a > node listening to the query sends a membership report for all multicast > addresses it is listening to, excluding the all-nodes link-local > multicast address and any multicast addresses of scope 0 (reserved) and > 1 (node-local). > > My question is, is the node required to send the membership report for > solicited-node multicast address as well? In general, since nodes do not > receive link-local scope multicast packets from out side the link, why > is it required for the nodes to report membership to the router for > *any* link-local scope multicast addresses? > > Thanks, > Siva > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 27 12:01:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RK1c7f013224; Thu, 27 Feb 2003 12:01:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RK1crQ013223; Thu, 27 Feb 2003 12:01:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RK1Y7f013216 for ; Thu, 27 Feb 2003 12:01:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RK1gVL017261 for ; Thu, 27 Feb 2003 12:01:42 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22672 for ; Thu, 27 Feb 2003 13:01:36 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:01:16 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 19:59:30 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:01:16 Z Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:01:15 Z Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RK0vYE028450; Thu, 27 Feb 2003 12:00:57 -0800 (PST) Received: from SIVAV.qualcomm.com (sivav.qualcomm.com [129.46.222.34]) by magus.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1RK0q9A003919; Thu, 27 Feb 2003 12:00:53 -0800 (PST) Message-Id: <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 12:00:52 -0800 To: Brian Haberman From: Siva Veerepalli Subject: Re: Question on MLD Cc: Siva Veerepalli , ipng@sunroof.eng.sun.com In-Reply-To: <3E5E67BE.3040201@nc.rr.com> References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:32 PM 2/27/2003 -0500, Brian Haberman wrote: >MLD-snooping switches is the biggest reason. Ok. So, it seems like there would be no need to send these reports for link-local multicast on point-to-point links. Should this clarification be made in the IPv6 over PPP RFC? thanks, Siva >Brian > >Siva Veerepalli wrote: >>RFC2710 (MLD) states that when a General Membership Query is received, a >>node listening to the query sends a membership report for all multicast >>addresses it is listening to, excluding the all-nodes link-local >>multicast address and any multicast addresses of scope 0 (reserved) and 1 >>(node-local). >>My question is, is the node required to send the membership report for >>solicited-node multicast address as well? In general, since nodes do not >>receive link-local scope multicast packets from out side the link, why is >>it required for the nodes to report membership to the router for *any* >>link-local scope multicast addresses? >>Thanks, >>Siva >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home 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 27 12:20:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RKKt7f013562; Thu, 27 Feb 2003 12:20:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RKKtfN013561; Thu, 27 Feb 2003 12:20:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RKKq7f013554 for ; Thu, 27 Feb 2003 12:20:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RKKxVL023930 for ; Thu, 27 Feb 2003 12:20:59 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15962 for ; Thu, 27 Feb 2003 13:20:53 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:20:52 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:18:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:20:45 Z Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 20:20:44 Z Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h1RKJ4oL015034; Thu, 27 Feb 2003 15:19:06 -0500 (EST) Received: from nc.rr.com ([66.26.252.32]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Feb 2003 15:18:25 -0500 Message-Id: <3E5E728B.6010904@nc.rr.com> Date: Thu, 27 Feb 2003 15:18:19 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Siva Veerepalli CC: ipng@sunroof.eng.sun.com Subject: Re: Question on MLD References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Siva Veerepalli wrote: > At 02:32 PM 2/27/2003 -0500, Brian Haberman wrote: > >> MLD-snooping switches is the biggest reason. > > > Ok. So, it seems like there would be no need to send these reports for > link-local multicast on point-to-point links. Should this clarification > be made in the IPv6 over PPP RFC? How many implementations of MLD pay attention to the link-type of the interface? All the MLD codebases that I have seen are interface-type agnostic and treat them all the same. I don't see the benefit of revving RFC 2472 to change this behavior. Regards, 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 Thu Feb 27 14:16:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RMGC7f014336; Thu, 27 Feb 2003 14:16:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RMGBKa014335; Thu, 27 Feb 2003 14:16:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RMG87f014328 for ; Thu, 27 Feb 2003 14:16:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RMGFVK012048 for ; Thu, 27 Feb 2003 14:16:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12523 for ; Thu, 27 Feb 2003 15:16:08 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:15:54 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:15:53 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:15:52 Z Received: from ALPHA6.ITS.MONASH.EDU.AU (ALPHA6.ITS.MONASH.EDU.AU [130.194.1.25]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:15:51 Z Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KSYSL9IA7W95NW3N@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 09:15:27 +1100 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A1F3A12C005; Fri, 28 Feb 2003 09:15:26 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 7624612C006; Fri, 28 Feb 2003 09:15:13 +1100 (EST) Date: Fri, 28 Feb 2003 09:15:10 +1100 From: Greg Daley Subject: Re: Question on MLD To: Siva Veerepalli Cc: Brian Haberman , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E5E8DEE.20902@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Siva, RFC 2462 says that the node MUST join the solicited-node multicast group (which implies using MLD) when performing DAD. Since the node has to send an MLD report in the first instance, there's no reason not to follow the rest of the MLD specification. Greg Siva Veerepalli wrote: > At 02:32 PM 2/27/2003 -0500, Brian Haberman wrote: > >> MLD-snooping switches is the biggest reason. > > > Ok. So, it seems like there would be no need to send these reports for > link-local multicast on point-to-point links. Should this clarification > be made in the IPv6 over PPP RFC? > > thanks, > Siva > > >> Brian >> >> Siva Veerepalli wrote: >> >>> RFC2710 (MLD) states that when a General Membership Query is >>> received, a node listening to the query sends a membership report for >>> all multicast addresses it is listening to, excluding the all-nodes >>> link-local multicast address and any multicast addresses of scope 0 >>> (reserved) and 1 (node-local). >>> My question is, is the node required to send the membership report >>> for solicited-node multicast address as well? In general, since nodes >>> do not receive link-local scope multicast packets from out side the >>> link, why is it required for the nodes to report membership to the >>> router for *any* link-local scope multicast addresses? >>> Thanks, >>> Siva >>> -------------------------------------------------------------------- >>> IETF IPng Working Group Mailing List >>> IPng Home 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 Thu Feb 27 14:37:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RMbb7f014967; Thu, 27 Feb 2003 14:37:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RMbbFh014966; Thu, 27 Feb 2003 14:37:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RMbY7f014958 for ; Thu, 27 Feb 2003 14:37:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RMbfVL007943 for ; Thu, 27 Feb 2003 14:37:41 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23659 for ; Thu, 27 Feb 2003 15:37:35 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:37:18 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:29:20 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:31:06 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 22:31:05 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1RMV3iC000857 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 28 Feb 2003 00:31:03 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1RMV3nM000853; Fri, 28 Feb 2003 00:31:03 +0200 Date: Fri, 28 Feb 2003 00:31:03 +0200 Message-Id: <200302272231.h1RMV3nM000853@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <3E5E8DEE.20902@eng.monash.edu.au> (message from Greg Daley on Fri, 28 Feb 2003 09:15:10 +1100) Subject: Re: Question on MLD References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> <3E5E8DEE.20902@eng.monash.edu.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC 2462 says that the node MUST join the solicited-node > multicast group (which implies using MLD) when performing > DAD. Presumably it needs to do the MLD join with ::-src address, because before DAD address is not yet valid. Personally, I think the spec is just plain wrong. I believe one should not use MLD on link local multicast groups. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 15:05:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RN5A7f015378; Thu, 27 Feb 2003 15:05:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RN5AbU015377; Thu, 27 Feb 2003 15:05:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RN567f015370 for ; Thu, 27 Feb 2003 15:05:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RN5DVL016988 for ; Thu, 27 Feb 2003 15:05:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14802 for ; Thu, 27 Feb 2003 16:05:05 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:04:56 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:04:56 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:04:55 Z Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:04:55 Z Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h1RN3Qo5016146; Thu, 27 Feb 2003 18:03:26 -0500 (EST) Received: from nc.rr.com ([66.26.252.32]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 27 Feb 2003 18:02:44 -0500 Message-Id: <3E5E9910.2000201@nc.rr.com> Date: Thu, 27 Feb 2003 18:02:40 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela CC: ipng@sunroof.eng.sun.com Subject: Re: Question on MLD References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> <3E5E8DEE.20902@eng.monash.edu.au> <200302272231.h1RMV3nM000853@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: >>RFC 2462 says that the node MUST join the solicited-node >>multicast group (which implies using MLD) when performing >>DAD. > > > Presumably it needs to do the MLD join with ::-src address, because > before DAD address is not yet valid. That is exactly what draft-ietf-magma-mld-source-04.txt is intended to correct. That draft is in front of the IESG at this time. > > Personally, I think the spec is just plain wrong. I believe one should > not use MLD on link local multicast groups. As I pointed out in an earlier message, MLD messages are necessary in order to deal with MLD snooping switches. 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 Thu Feb 27 15:28:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RNRx7f015720; Thu, 27 Feb 2003 15:27:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1RNRxq1015719; Thu, 27 Feb 2003 15:27:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1RNRt7f015712 for ; Thu, 27 Feb 2003 15:27:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1RNS2VK005109 for ; Thu, 27 Feb 2003 15:28:02 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05922 for ; Thu, 27 Feb 2003 15:27:57 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:27:56 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:27:56 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:27:55 Z Received: from ALPHA6.ITS.MONASH.EDU.AU (ALPHA6.ITS.MONASH.EDU.AU [130.194.1.25]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Feb 2003 23:27:55 Z Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KSYV3J260O96VW95@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 10:27:27 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D75313000A; Fri, 28 Feb 2003 10:27:26 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 81B8B130003; Fri, 28 Feb 2003 10:27:12 +1100 (EST) Date: Fri, 28 Feb 2003 10:27:12 +1100 From: Greg Daley Subject: Re: Question on MLD To: Markku Savela Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E5E9ED0.3010809@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> <4.3.2.7.2.20030227115712.051b6da0@jittlov.qualcomm.com> <3E5E8DEE.20902@eng.monash.edu.au> <200302272231.h1RMV3nM000853@burp.tkv.asdf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Markku, Markku Savela wrote: >>RFC 2462 says that the node MUST join the solicited-node >>multicast group (which implies using MLD) when performing >>DAD. > > > Presumably it needs to do the MLD join with ::-src address, because > before DAD address is not yet valid. Yes. Currently there is a MAGMA draft describing this. draft-ietf-magma-mld-source-04.txt > Personally, I think the spec is just plain wrong. I believe one should > not use MLD on link local multicast groups. This is similar to the previous discussion on MLD-snooping switches. Essentially the role of joining a multicast group is to create state in the network. With non-local multicast groups this has an effect on routing infrastructure. If MLD snooping switches are a likelihood in future networks, then I think it is reasonable that nodes joining a multicast group create state for them, whether the packets are link-local or have greater scope. In the mean time it is a requirement which is widely ignored by implementors. 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 Thu Feb 27 16:47:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S0l07f016943; Thu, 27 Feb 2003 16:47:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S0l0ZR016942; Thu, 27 Feb 2003 16:47:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S0ku7f016935 for ; Thu, 27 Feb 2003 16:46:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S0l4VL020301 for ; Thu, 27 Feb 2003 16:47:04 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19999 for ; Thu, 27 Feb 2003 16:46:57 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 00:46:54 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 00:46:47 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 00:46:47 Z Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 00:46:45 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1S0kc56017744; Thu, 27 Feb 2003 16:46:39 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA09304; Fri, 28 Feb 2003 00:46:37 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt From: Ole Troan Date: Fri, 28 Feb 2003 00:46:37 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Wed, 26 Feb 2003 16:55:12 +0900") Message-Id: <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei-san, thanks for your comments! answers inline. >> Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and >> reply with comments. If you recommend the document for advancement without >> revision, please respond with a quick acknowledgment. No response will be >> interpreted as a lack of support for advancing the document. > > I've finally reviewed the latest draft. As I said before, I basically > support the document. However, I don't think the current revision is > ready to be published. IMO, it is still incomplete and has not fully > addressed open issues. > > Detailed comments follow: > > 1. Issues about the preferred and valid lifetimes were not fully > addressed. I've not seen consensus on this in the dhc-wg ML. > Please re-check the thread entitled "PD lifetimes" that started on > Thu, 23 Jan 2003 19:18:57 +0900. what specifically are you referring to here? in my opinion we reached consensus that: - both preferred and valid lifetimes are needed - prefixes or addresses derived from the prefix MUST not be used beyond the valid lifetime - adding P and V bits to specify if a prefix advertised in an RA should use a fixed lifetime or a real time lifetime, is not needed as it does not seem to add value or solve any specific problem. > 2. Section 11.1 now specifies the requesting router to use > Rebind/Reply exchanges to verify an existing binding (instead of > Renew/Reply exchanges). According to the very recent > clarifications on the base DHCPv6 spec, however, I'm not sure if > Rebind is appropriate here; the server should drop the Rebind > message unless it has an explicit knowledge about the validity or > invalidity of the prefix, which should not be the case (e.g.) when > the upstream link flaps. Rebind now behaves just like Confirm. if by link flap you mean change of link to another delegating router, the delegating router can reply to a Rebind even without a binding if it knows through explicit configuration that the prefixes in the IA_PD is not valid for the link. > 3. Section 10.2 contains the following sentence (newly added in the > latest revision): > > If the delegating router cannot delegate any prefixes to an IA_PD in > the message from the requesting router, the delegating router MUST > include the IA_PD in the Reply message with no prefixes in the IA_PD > and a Status Code option in the IA_PD containing status code > NoPrefixAvail. > > I guess the "Reply" should be "Advertisement" here, because this > section is talking about "Delegating Router Solicitation." I also > guess the sentence was added in response to a question of mine in > the ML. If so, a similar clarification should be introduced to > Section 11.2 as well. Additionally, the corresponding client > behaviors should also be documented. yes, well spotted. > 4. The PD draft should reflect some parts of > draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections > 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. I have made the changes where appropriate, i.e where we already have cut and pasted text from the DHCPv6 base specification. > We may be able to omit some of them as trivial clarifications, but > we should reflect some other part of them because the base DHCPv6 > spec (and thus the clarifications for it) is too specific to > address assignment. In some cases, implementors can use analogy of > the base spec to implement the PD draft, but we should basically > provide comprehensive information in the PD draft itself to ensure > better interoperability. (As some people, including me, have > repeatedly pointed out, the best approach would be to make the base > spec generic so that each stateful method can just refer to the > base spec. Since we could not make it due to the "it's too late" > reason, we should be responsible to implementors for providing > detailed information within the PD specification). the PD specification is not meant to be complete and needs to be read in conjunction with the base DHCP specification. /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 27 20:30:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S4U97f017908; Thu, 27 Feb 2003 20:30:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S4U8Op017907; Thu, 27 Feb 2003 20:30:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S4U37f017896 for ; Thu, 27 Feb 2003 20:30:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S4UAVK029402 for ; Thu, 27 Feb 2003 20:30:10 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01716 for ; Thu, 27 Feb 2003 21:30:04 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 04:29:57 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 04:29:56 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 04:29:56 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 04:29:56 Z Subject: RE: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Date: Thu, 27 Feb 2003 20:29:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C4D@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Thread-Index: AcLYEmYYjF6N/QoYQTexmX3JhO0/owGzHX/w From: "Michel Py" To: Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1S4U37f017901 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > Title : IPv6 Documentation Address > Author(s) : G. Huston, A. Lord, P. Smith > Filename : draft-huston-ipv6-documentation-prefix-00.txt This text is a good beginning, but as I mentioned earlier a single /32 is not enough to document multihoming scenarios. A site receives connectivity from 3 LIRs; the site is assigned three /48s. It would be confusing to make these three /48 part of the same /32 as lots of people would assume that a LIR gets a /32 as it is current policy. Example: Prefix assigned by LIR 1: 2001:0DB8:1234::/48 Prefix assigned by LIR 2: 2001:0DB8:5678::/48 Prefix assigned by LIR 3: 2001:0DB8:ABCD::/48 Something does not register here, as people might assume that LIRs 1,2 and 3 are tier-2 or -3 LIRs that all get transit from a bigger tier-1 LIR that has been allocated 2001:0DB8::/32 (which defeats half of the reasons to multihome). The purpose of the documentation prefix is double: 1. Avoid using addresses that could be assigned to a site. 2. Avoid using things such as: Prefix assigned by LIR 1: 2001:x:y::/48 Prefix assigned by LIR 2: 2001:a:b::/48 Prefix assigned by LIR 3: 2001:c:d::/48 Editorial: including the email addresses of the authors in the text would not hurt anyone. 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 27 21:05:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S5577f018298; Thu, 27 Feb 2003 21:05:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S556Z4018297; Thu, 27 Feb 2003 21:05:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S5537f018290 for ; Thu, 27 Feb 2003 21:05:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S55AVK006063 for ; Thu, 27 Feb 2003 21:05:10 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21322 for ; Thu, 27 Feb 2003 21:05:04 -0800 (PST) From: john.loughney@Nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 05:05:00 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 05:02:23 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 05:04:10 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 05:04:09 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1S57Im11098 for ; Fri, 28 Feb 2003 07:07:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 07:04:08 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 07:04:07 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 07:04:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 router requirements Date: Fri, 28 Feb 2003 07:04:06 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 router requirements Thread-Index: AcLeo8XqZewhOHizS7ekJ9cWccQhJQAQt7ew To: Cc: , X-OriginalArrivalTime: 28 Feb 2003 05:04:07.0330 (UTC) FILETIME=[D2625820:01C2DEE6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1S5537f018291 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steph, Of of the top of my head, I do not know. Does anyone have an opinion? br, John > -----Original Message----- > From: ext Stephen Bailey [mailto:steph@sandburst.com] > Sent: 27 February, 2003 22:45 > To: Loughney John (NRC/Helsinki) > Cc: steph@cs.uchicago.edu > Subject: IPv6 router requirements > > > Hi John, > > Do you have a suggestion of somebody who could tell me if an > IPv6 router > is required to perform host discovery for host routes? > > Thanks, > Steph > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 27 23:45:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7jq7f020299; Thu, 27 Feb 2003 23:45:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S7jpIr020298; Thu, 27 Feb 2003 23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7jm7f020291 for ; Thu, 27 Feb 2003 23:45:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S7jtVK005592 for ; Thu, 27 Feb 2003 23:45:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05136 for ; Fri, 28 Feb 2003 00:45:49 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:45:48 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:45:48 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:45:48 Z Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:45:47 Z Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1S7jknS019648; Fri, 28 Feb 2003 08:45:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Feb 2003 08:45:46 +0100 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF6CA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , steph@sandburst.com Cc: ipng@sunroof.eng.sun.com, steph@cs.uchicago.edu Subject: RE: IPv6 router requirements Date: Fri, 28 Feb 2003 08:45:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Do you have a suggestion of somebody who could tell me if an > > IPv6 router > > is required to perform host discovery for host routes? => what do you mean by host discovery? Is the router sharing a link with the host? Hesham > > > > Thanks, > > Steph > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 27 23:52:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7qK7f020360; Thu, 27 Feb 2003 23:52:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S7qJGm020359; Thu, 27 Feb 2003 23:52:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7qF7f020352 for ; Thu, 27 Feb 2003 23:52:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S7qNVL022915 for ; Thu, 27 Feb 2003 23:52:23 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00085 for ; Thu, 27 Feb 2003 23:52:17 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:52:15 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:52:15 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:52:15 Z Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:52:15 Z Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1S7ppVR021016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Fri, 28 Feb 2003 08:51:51 +0100 X-pt: isis.lip6.fr Received: from gargamel (rp [132.227.74.3]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1S7po321647; Fri, 28 Feb 2003 08:51:50 +0100 (MET) From: "Konstantin KABASSANOV" To: "'Siva Veerepalli'" , Subject: RE: Question on MLD Date: Fri, 28 Feb 2003 08:52:24 +0100 Message-Id: <000001c2defe$553dd410$8648e384@ipv6.lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4.3.2.7.2.20030227110735.01539140@jittlov.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1S7qG7f020353 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In particular this kind of messages can be useful for mld snooping switches. Konstantin _____________________________________________________ Konstantin K. KABASSANOV Research and Development Engineer LIP6 Laboratory Pierre and Marie Curie University 8, rue du Capitaine Scott, 75015 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: konstantin@kabassanov.com Web: http://www.kabassanov.com ______________________________________________________ > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Siva Veerepalli > Sent: jeudi 27 février 2003 20:23 > To: ipng@sunroof.eng.sun.com > Subject: Question on MLD > > RFC2710 (MLD) states that when a General Membership Query is received, a > node listening to the query sends a membership report for all multicast > addresses it is listening to, excluding the all-nodes link-local multicast > address and any multicast addresses of scope 0 (reserved) and 1 (node- > local). > > My question is, is the node required to send the membership report for > solicited-node multicast address as well? In general, since nodes do not > receive link-local scope multicast packets from out side the link, why is > it required for the nodes to report membership to the router for *any* > link-local scope multicast addresses? > > Thanks, > Siva > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 27 23:54:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7s37f020430; Thu, 27 Feb 2003 23:54:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1S7s38c020429; Thu, 27 Feb 2003 23:54:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1S7rw7f020419 for ; Thu, 27 Feb 2003 23:53:59 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1S7s6VL023229 for ; Thu, 27 Feb 2003 23:54:06 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01086 for ; Thu, 27 Feb 2003 23:54:00 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:53:58 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:53:57 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:53:57 Z Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 07:53:56 Z Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1S7rnVR021151 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Fri, 28 Feb 2003 08:53:49 +0100 X-pt: isis.lip6.fr Received: from gargamel (rp [132.227.74.3]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1S7rm321672; Fri, 28 Feb 2003 08:53:48 +0100 (MET) From: "Konstantin KABASSANOV" To: "'Siva Veerepalli'" , Subject: RE: Question on MLD Date: Fri, 28 Feb 2003 08:54:23 +0100 Message-Id: <000101c2defe$9b760e20$8648e384@ipv6.lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1S7rx7f020420 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I did not see all answers you had already got ... Konstantin > -----Original Message----- > From: Konstantin KABASSANOV [mailto:Konstantin.Kabassanov@lip6.fr] > Sent: vendredi 28 février 2003 08:52 > To: 'Siva Veerepalli'; 'ipng@sunroof.eng.sun.com' > Subject: RE: Question on MLD > > Hi, > > In particular this kind of messages can be useful for mld snooping > switches. > > Konstantin > > _____________________________________________________ > > Konstantin K. KABASSANOV > Research and Development Engineer > > LIP6 Laboratory > Pierre and Marie Curie University > > 8, rue du Capitaine Scott, > 75015 Paris, France > > Phone: +33 (0) 1 44 27 71 26 > Fax: +33 (0) 1 44 27 74 95 > > E-mail: konstantin@kabassanov.com > Web: http://www.kabassanov.com > ______________________________________________________ > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > > ipng@sunroof.eng.sun.com] On Behalf Of Siva Veerepalli > > Sent: jeudi 27 février 2003 20:23 > > To: ipng@sunroof.eng.sun.com > > Subject: Question on MLD > > > > RFC2710 (MLD) states that when a General Membership Query is received, a > > node listening to the query sends a membership report for all multicast > > addresses it is listening to, excluding the all-nodes link-local > multicast > > address and any multicast addresses of scope 0 (reserved) and 1 (node- > > local). > > > > My question is, is the node required to send the membership report for > > solicited-node multicast address as well? In general, since nodes do not > > receive link-local scope multicast packets from out side the link, why > is > > it required for the nodes to report membership to the router for *any* > > link-local scope multicast addresses? > > > > Thanks, > > Siva > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 28 02:12:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SACl7f021409; Fri, 28 Feb 2003 02:12:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SACl0S021408; Fri, 28 Feb 2003 02:12:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SACi7f021401 for ; Fri, 28 Feb 2003 02:12:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SACpVK003505 for ; Fri, 28 Feb 2003 02:12:51 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29832 for ; Fri, 28 Feb 2003 03:12:46 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 10:12:04 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 10:11:35 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 10:11:34 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 10:11:34 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1SABSh01800; Fri, 28 Feb 2003 11:11:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1SA82of071888; Fri, 28 Feb 2003 11:08:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302281008.h1SA82of071888@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman cc: ipng@sunroof.eng.sun.com Subject: Re: Question on MLD In-reply-to: Your message of Thu, 27 Feb 2003 18:02:40 EST. <3E5E9910.2000201@nc.rr.com> Date: Fri, 28 Feb 2003 11:08:02 +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: That is exactly what draft-ietf-magma-mld-source-04.txt is intended to correct. That draft is in front of the IESG at this time. As I pointed out in an earlier message, MLD messages are necessary in order to deal with MLD snooping switches. => I fully agree and my old code always sent the first MLD reports from the unspecified address. I never see an issue there (MLD report is one of the third cases of unspecified sources with DAD and early RS). And snooping switches are *great* when you have multicasts on a mixed speed Ethernet (which is near always the case, unfortunately they don't snoop MLD (i.e., they support only IPv4/ICMP) today). 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 Fri Feb 28 03:35:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SBZI7f021824; Fri, 28 Feb 2003 03:35:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SBZHXj021823; Fri, 28 Feb 2003 03: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SBZE7f021816 for ; Fri, 28 Feb 2003 03:35:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SBZNVL027527 for ; Fri, 28 Feb 2003 03:35:23 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10591 for ; Fri, 28 Feb 2003 04:35:17 -0700 (MST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 11:35:12 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 11:35:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 11:35:12 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 11:35:12 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SBcLm19275 for ; Fri, 28 Feb 2003 13:38:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Feb 2003 13:35:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 13:35:10 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 13:35:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Missing reference in 2732 Date: Fri, 28 Feb 2003 13:35:08 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Thread-Index: AcLd+SleRYSx2dp6RuqRZo84rUj5XwBJAzxg To: X-OriginalArrivalTime: 28 Feb 2003 11:35:09.0821 (UTC) FILETIME=[731E5AD0:01C2DF1D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h1SBZF7f021817 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, If anyone is keeping track, 2732 (http://www.ietf.org/rfc/rfc2732.txt) - Format for Literal IPv6 Addresses in URL's. says: 1.1 Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear in this document, are to be interpreted as described in [KEYWORDS]. but is missing [KEYWORDS] in the Reference section. br, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 28 06:01:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SE197f023041; Fri, 28 Feb 2003 06:01:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SE194o023040; Fri, 28 Feb 2003 06:01:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SE167f023033 for ; Fri, 28 Feb 2003 06:01:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SE1EVL020569 for ; Fri, 28 Feb 2003 06:01:15 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00040 for ; Fri, 28 Feb 2003 07:01:03 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 14:01:00 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 14:00:58 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 14:00:57 Z Received: from geto.cysol.co.jp (geto.cysol.co.jp [210.233.3.227]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 14:00:55 Z Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by geto.cysol.co.jp (8.11.3/3.7W) with ESMTP id h1SE0fs19478; Fri, 28 Feb 2003 23:00:41 +0900 (JST) Received: from localhost (azuma.priv.cysol.co.jp [192.168.0.52]) by aso.priv.cysol.co.jp (8.12.7/8.12.7) with ESMTP id h1SE0c72003407; Fri, 28 Feb 2003 23:00:39 +0900 (JST) Date: Fri, 28 Feb 2003 23:00:38 +0900 (JST) Message-Id: <20030228.230038.32592908.abekatsu@cysols.com> To: hesham.soliman@era.ericsson.se Cc: john.loughney@Nokia.com, steph@sandburst.com, ipng@sunroof.eng.sun.com, steph@cs.uchicago.edu, abekatsu@cysols.com Subject: Re: IPv6 router requirements From: Katsuhisa ABE In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF6CA@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053807FEF6CA@Esealnt861.al.sw.ericsson.se> X-Mailer: Mew version 3.1.50 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Hesham Soliman (EAB)" Subject: RE: IPv6 router requirements Date: Fri, 28 Feb 2003 08:45:41 +0100 > > > Do you have a suggestion of somebody who could tell me if an > > > IPv6 router > > > is required to perform host discovery for host routes? > > => what do you mean by host discovery? Is the router sharing > a link with the host? > Are the discovery targets MAC address/hostname/IPv6 addresses? If router response the above information, for example, "Node Information Queries Proxy"(*1), it is a pleasure for the network administrator to manage the IPv6 local network. (*1) Node Information Queries Proxy >From "IPv6 Node Information Queries" , >5.3.1. Discussion > > Because a node can only answer a Node Name Request when it is up and > reachable, it may be useful to create a proxy responder for a group > of nodes, for example a subnet or a site. Such a mechanism is not > addressed here. Regards, Katsuhisa ABE -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 28 07:05:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SF5J7f023476; Fri, 28 Feb 2003 07:05:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SF5I6I023475; Fri, 28 Feb 2003 07:05:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SF5F7f023468 for ; Fri, 28 Feb 2003 07:05:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SF5OVK026496 for ; Fri, 28 Feb 2003 07:05:24 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07016 for ; Fri, 28 Feb 2003 08:05:18 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 15:04:14 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 15:02:09 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 15:03:57 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 15:03:56 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1SF3mEI079876; Fri, 28 Feb 2003 16:03:49 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1SF3kd7026736; Fri, 28 Feb 2003 16:03:47 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54632 from ; Fri, 28 Feb 2003 16:03:43 +0100 Message-Id: <3E5F7A18.3AFF0A64@hursley.ibm.com> Date: Fri, 28 Feb 2003 16:02:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: john.loughney@Nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Missing reference in 2732 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I'll file that away, but the last I heard was that the URI people would suck 2732 into an update of 2396, one of these years. Thanks Brian john.loughney@nokia.com wrote: > > Hi all, > > If anyone is keeping track, 2732 (http://www.ietf.org/rfc/rfc2732.txt) > - Format for Literal IPv6 Addresses in URL's. > > says: > > 1.1 Requirements > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear > in this document, are to be interpreted as described in [KEYWORDS]. > > but is missing [KEYWORDS] in the Reference section. > > br, > John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 28 08:13:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SGDe7f024209; Fri, 28 Feb 2003 08:13:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SGDenb024208; Fri, 28 Feb 2003 08:13:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SGDa7f024201 for ; Fri, 28 Feb 2003 08:13:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SGDkVL019488 for ; Fri, 28 Feb 2003 08:13:46 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25775 for ; Fri, 28 Feb 2003 08:13:39 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 16:13:38 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 16:13:38 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 16:13:38 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 16:13:37 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGDXJR017911; Fri, 28 Feb 2003 11:13:34 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12518; Fri, 28 Feb 2003 11:13:33 -0500 (EST) Message-Id: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 11:13:32 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Results from interoperability testing of DHCPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We did some interoperability testing of independent DHCPv6 implementations at the recent TAHI interoperability testing event. I've published a list of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, identified through the interoperability testing. The DHCPv6 specification has been accepted as a Proposed Standard, but has not yet been published as an RFC. To improve the text in the spec based on our experience with the interoperability testing, I will make the editorial clarifications listed as "resolution" in draft-ietf-dhc-dhcpv6-interop-00.txt prior to publication of the DHCPv6 RFC. Please review draft-ietf-dhc-dhcpv6-interop-00.txt and respond with any comments to the dhcwg mailing list. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 28 09:35:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHZO7f024963; Fri, 28 Feb 2003 09:35:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SHZO6T024962; Fri, 28 Feb 2003 09:35:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHZJ7f024955 for ; Fri, 28 Feb 2003 09:35:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SHZSVL014791 for ; Fri, 28 Feb 2003 09:35:28 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18518 for ; Fri, 28 Feb 2003 09:35:21 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:26:54 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:17:13 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:19:02 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:19:01 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 712C715210; Sat, 1 Mar 2003 02:19:20 +0900 (JST) Date: Sat, 01 Mar 2003 02:19:09 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Results from interoperability testing of DHCPv6 In-Reply-To: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> References: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Feb 2003 11:13:32 -0500, >>>>> Ralph Droms said: > We did some interoperability testing thof independent DHCPv6 implementations > at the recent TAHI interoperability testing event. I've published a list > of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, identified through the > interoperability testing. > The DHCPv6 specification has been accepted as a Proposed Standard, but has > not yet been published as an RFC. To improve the text in the spec based on > our experience with the interoperability testing, I will make the editorial > clarifications listed as "resolution" in > draft-ietf-dhc-dhcpv6-interop-00.txt prior to publication of the DHCPv6 RFC. > Please review draft-ietf-dhc-dhcpv6-interop-00.txt and respond with any > comments to the dhcwg mailing list. For the record, I fully support the action; I support the DHCPv6 spec to be published, and I belive it would be great if the published version of the DHCPv6 spec contains the clarifications described in the dhcpv6-interop draft. (Since I happened to have a chance to review the clarification draft beforehand, I don't have further comments on 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 Fri Feb 28 09:50:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHo87f025371; Fri, 28 Feb 2003 09:50:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SHo80C025370; Fri, 28 Feb 2003 09:50:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHo47f025363 for ; Fri, 28 Feb 2003 09:50:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SHoDVK010259 for ; Fri, 28 Feb 2003 09:50:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08653 for ; Fri, 28 Feb 2003 10:50:05 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:50:03 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:48:12 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:50:00 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:49:59 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHnrNh014087; Fri, 28 Feb 2003 12:49:54 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20367; Fri, 28 Feb 2003 12:49:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030228124404.0378ceb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 12:49:52 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Revision of DHCPv6 DNS configuration options Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've revised "DNS Configuration options for DHCPv6" based on input received during the WG last call. Here is the summary of changes to the document: Changes from draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt This document includes the following changes in response to comments made during the dhc/dnsext WG last call: o Combined RFC2119 reference and reference to DHCPv6 specification into one "Terminology" section; added explicit normative reference to DHCPv6 specification. o Changed name of "Domain Name Server" option to "DNS Resolver" option. o Clarified and corrected filed names and descriptions of fields in the option format diagrams. o Reworded "Appearance of these options" for clarity; removed Confirm from list of messages in which the options can appear. o Clarified the type of attack that can be mounted through the Domain Search List option by copying text from RFC3997 As these changes are editorial or clarifying, draft-ietf-dhc-dhcpv6 opt-dnsconfig-03.txt is ready for IESG review as a Proposed Standard. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 28 09:53:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHrU7f025515; Fri, 28 Feb 2003 09:53:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SHrUnl025514; Fri, 28 Feb 2003 09:53:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SHrQ7f025495 for ; Fri, 28 Feb 2003 09:53:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SHrZVL022643 for ; Fri, 28 Feb 2003 09:53:35 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14524 for ; Fri, 28 Feb 2003 09:53:28 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 17:53:17 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP; Fri, 28 Feb 2003 17:53:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 28 Feb 2003 17:53:16 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP; Fri, 28 Feb 2003 17:53:15 Z 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 JAA03700; Fri, 28 Feb 2003 09:53:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1SHr3t13035; Fri, 28 Feb 2003 09:53:03 -0800 X-mProtect: <200302281753> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvgWuFG; Fri, 28 Feb 2003 09:53:00 PST Message-Id: <4.3.2.7.2.20030228094545.037fcc10@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 09:52:37 -0800 To: Thomas Narten , Erik Nordmark From: Bob Hinden & Margaret Wasserman Subject: Follow up to IAB response to Robert Elz's Appeal Cc: ipng@sunroof.eng.sun.com, ietf-secretariat@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Erik, The chairs belive that based on the email on the mailing list there is a consensus in the IPv6 working group to publish the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) as a Proposed Standard as recommended below. Bob Hinden and Margaret Wasserman IPv6 working group chairs >Date: Tue, 25 Feb 2003 16:01:09 -0800 >To: ipng@sunroof.eng.sun.com >From: Bob Hinden >Subject: Follow up to IAB response to Robert Elz's Appeal >Sender: owner-ipng@sunroof.eng.sun.com > >The IAB has responded to an appeal from Robert Elz of the IESG decision >to approve the IPv6 Addressing Architecture >(draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document >should not be published as a Draft Standard [1]. Given that the revised >document is a significant improvement over RFC 2473, and that RFC2473 is >badly out of date, we believe it is desirable to go ahead and publish the >document as a Proposed Standard at this time ASAP in order to get a >replacement to RFC2473 out. > >In parallel, it would be appropriate to discuss the details of the IAB >response and how the WG wishes to respond to the IAB >recommendations. Note that approving the document as PS at this time does >not imply that the WG agrees with all of the IAB's recommendations nor >does it preclude any particular follow-on action by the WG or >IESG. However, approval at PS is something that can be done relatively >quickly. > >Does this approach make sense to the WG? > >Bob Hinden, Margaret Wasserman; IPv6 Chairs >Thomas Narten, Erik Nordmark; Internet ADs > >[1] IAB, "Re: Appeal against IESG decision", >http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 28 11:01:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SJ1t7f026642; Fri, 28 Feb 2003 11:01:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h1SJ1su7026641; Fri, 28 Feb 2003 11:01:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h1SJ1p7f026634 for ; Fri, 28 Feb 2003 11:01:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h1SJ20VL016924 for ; Fri, 28 Feb 2003 11:02:00 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25861 for ; Fri, 28 Feb 2003 12:01:54 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 19:01:54 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 19:01:34 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 19:01:34 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Feb 2003 19:01:34 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.31]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA28528; Fri, 28 Feb 2003 11:00:07 -0800 (PST) Message-Id: <5.1.0.14.2.20030228134823.036aed08@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Feb 2003 13:51:47 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: IPv6 router requirements 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 > > Do you have a suggestion of somebody who could tell me if an > > IPv6 router > > is required to perform host discovery for host routes? > > I'm sorry, but I don't completely understand the question... If a router has a host route in its routing table, it doesn't need to do any "checking" on that validity of that host router (i.e. neighbor discovery(ND), neighbor unreachability detection, etc.). However, if a router wants to send a packet to a host on a local link, it will use ND to determine if the host is reachable and get link-layer address information, if needed. Do either of those statement answer your question? 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 --------------------------------------------------------------------