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