From owner-ipng@sunroof.eng.sun.com Tue Oct 1 00:39:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g917dxbj000222; Tue, 1 Oct 2002 00:39:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g917dxrM000221; Tue, 1 Oct 2002 00:39:59 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g917dmbj000204; Tue, 1 Oct 2002 00:39:49 -0700 (PDT) Received: from sun.com (vpn-129-159-0-21.EMEA.Sun.COM [129.159.0.21]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g917doA02369; Tue, 1 Oct 2002 09:39:50 +0200 (MEST) Message-ID: <3D99513D.3090204@sun.com> Date: Tue, 01 Oct 2002 09:39:41 +0200 From: gabriel montenegro Reply-To: gab@Sun.COM User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: MIPv6 issue: HAO keyword Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an attempt to close issue 53 in the MIPv6 draft ("HAO keyword"): http://www.piuha.net/~jarkko/publications/mipv6/issues/issue53.txt We're cross-posting to both IPv6 and MobileIP as this concerns both lists. I'm sending this on behalf of Jari Arkko and the Mobile IP chairs. Please send any issues to the lists. tnx, -gabriel -------------------------------------------------------------- In July we had a big discussion around the right keyword for the Home Address destination option support in IPv6 nodes. This e-mail reviews the issue and makes a recommendation. Unless otherwise specified, section numbers refer to rev 18 of the draft: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt BACKGROUND In the new security design for Mobile IPv6 (adopted to the base specification over the course of the last year), we allow two modes of operation for communicating with the correspondent nodes: 1. Tunneling via the home agent (also called "reverse tunneling" in section 11.2.1). 2. Route Optimization (also called "direct delivery" in section 11.2.1): routing directly from the mobile node to the correspondent node (using a "home address option"), and from the correspondent node to the mobile node (using a "routing header - type 2"). Note that tunneling happens in *both* directions and that optimal routing can *only* be performed if a binding cache entry has been established. The mobile node can't send a packet directly to the correspondent node until it has completed return routability procedure and sent a binding update. This is a change from previous versions of the protocol and was done in order to guard against certain reflection attacks. (But see below for a special case.) The return routability procedure and binding updates are carried by the Mobility Header protocol (a new IPv6 protocol). According to RFC 2463, any node that doesn't recognize a specific "next header" protocol value will return ICMP Parameter Problem, Code 1 to the sender. The MIPv6 specification requires that the reception of such a message is taken as an indication that the peer does not support Route Optimization. Furthermore, even nodes that support MIPv6 may decline requests for Route Optimization due to temporary lack of resources, for instance. This happens via an error response within the Mobility Header protocol itself. The new version of MIPv6 protocol is therefore capable of operating both with nodes that support this specification (regardless of any temporary inability to accept requests) and with nodes that do not support MIPv6 (such as nodes that have already been deployed). The current MIPv6 specification lists the benefits of route optimization (Section 8.2) but does not state whether it is mandatory or not for all IPv6 nodes. The plan is to leave that for the IPv6 node requirements document to decide. THE PROBLEM Even though it does not mandate route optimization itself, the current MIPv6 spec does mandate that two items MUST be implemented by *all* IPv6 nodes (section 8.1): 1. All IPv6 nodes MUST recognize the Home Address destination option and, 2. All IPv6 nodes MUST be able to return Mobility Header error messages. However, several people have complained that in the current state of IPv6 deployment, they do not wish to add new requirements for all nodes. As explained above, this isn't technically necessary as the ICMP Parameter Problems (or the lack of response) is adequate to keep the mobile node using tunneling. No payload packets will be sent to the wrong place, and no packets are lost. However, these two requirements relate to a special case we currently allow in the specification: direct delivery from the mobile node to the correspondent node (which uses a home address destination option) is allowed not just when a binding exists but also if the packets have been protected by IPsec. This constitutes "triangular routing": whereas the mobile node can directly deliver packets to the correspondent node by virtue of IPsec, the opposite is not true: the reverse direction cannot be optimized if the correspondent node does not have a binding for the mobile node. Although allowed, triangular routing is not adequately described in the current spec (more below). Note that in any case a correspondent node that doesn't support the Home Address destination option will send ICMP Parameter Problem, Code 2, so that the mobile node may learn the fact that this node is of an older variant that doesn't support this option, and continues using reverse tunneling. ALTERNATIVES The main question in the debate was to choose: 1. Remove the current requirements for all nodes. 2. Keep the current requirements for all nodes. However, we also have some additional questions to answer: - Should triangular routing (the IPsec-protected HAO) mode be a part of the Mobile IPv6 specification, even as optional? - What is the right keyword for Route Optimization support in correspondent nodes? - Should the MIPv6 specification state all these requirements for IPv6 nodes, or the IPv6 node requirements document? ANALYSIS - Mobile nodes that try to improve upon reverse tunneling by either route optimization or triangular routing can survive a situation where they connect to an older node with no MIPv6 support at all. In this case they can fall back to reverse tunneling mode which does not require any support from the correspondent node. - We need to separate the technical requirements for mandating a specific protocol function (e.g. saying that "route optimization or some part of it is mandatory"), and more high level requirements (e.g. saying "security is mandatory"). - It is likely that obtaining an IPsec security association between a mobile node and an arbitrary correspondent node continues to be difficult. Even if possible, it may not be justifiable for the mobile node to either (1) obtain such a security association (e.g. if the traffic pattern consists of access to public web sites), or (2) obtain it and stop without spending the negligible *additional* effort to create a binding entry. This implies that the main modes would be reverse tunneling and route optimization, whereas triangular routing via the IPsec-protected HAO would be perhaps less often used. - The IPsec-protected HAO mode is inadequately described in the current specification. Section 9.2.2 describes this possibility for the correspondent node, but not for the mobile node in 11.2.1. This can be easily fixed, however. - If we removed the IPsec-protected HAO mode from the specification along with the HAO requirement, the effect would be that even nodes that use IPsec would have to establish a binding before any optimization is possible. Establishing a binding requires 1.5 roundtrips every 7 minutes. Of course, such nodes can continue using reverse tunneling. Note that the establishment of the binding can take place in parallel with the security association establishment. - RFC 2119 states on the use of imperatives in RFC's: "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." In this respect, the "MUST" keywords on HAO processing & error message requirements do not seem necessary, as (1) interoperability is already achieved using other mechanisms (ICMP/lack of answer and reverse tunneling via the home agent), and (2) for the mode that could potentially benefit from this the difference is not catastrophic as explained in the previous bullet. RECOMMENDATION The requirements of RFC 2119 for a "MUST" are not fulfilled in this case: interoperability is achieved in any case. Furthermore, it is questionable that nodes that bother to set up an IPsec security association would not be able to afford a much smaller amount of memory for a binding cache entry, particularly when bidirectionally optimal routing can only be achieved with Route Optimization. Therefore, we recommend that the HAO processing and error message MUST requirements be removed for all nodes. Instead, we recommend that Route Optimization support for correspondent nodes be made a SHOULD in the IPv6 node requirements document. The ability of a correspondent node to participate in route optimization is good for the efficient operation of the IPv6 Internet, beneficial for robustness and reduction of jitter and latency, and is in some cases necessary to avoid congestion in the home network. We also recommend that triangular routing via the IPsec-protected HAO processing be described in the Mobile IPv6 base specification, and be made a SHOULD for mobile and correspondent nodes. This includes describing how nodes can survive the situation where the other side does not support this mode. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 1 09:09:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91G9Tbj002273; Tue, 1 Oct 2002 09:09:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g91G9TuN002272; Tue, 1 Oct 2002 09:09:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91G9Nbj002259; Tue, 1 Oct 2002 09:09:23 -0700 (PDT) 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 g91G9SPG008999; Tue, 1 Oct 2002 09:09:28 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18691; Tue, 1 Oct 2002 10:09:22 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g91G9LIm016077; Tue, 1 Oct 2002 09:09:21 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE51752; Tue, 1 Oct 2002 09:03:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03487; Tue, 1 Oct 2002 09:09:20 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15769.51376.605194.114670@thomasm-u1.cisco.com> Date: Tue, 1 Oct 2002 09:09:20 -0700 (PDT) To: gab@Sun.COM Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: MIPv6 issue: HAO keyword In-Reply-To: <3D99513D.3090204@sun.com> References: <3D99513D.3090204@sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gabriel, On the requirement for HAO in all IPv6 nodes... is this actually necessary? That is, if I do not implement a binding cache (which is not a requirment), the only processing the node would need to do is inform the mobile node that it can not/will not process the HAO because it's not legal to interpret it as a home address without a binding entry. Likewise, a MN shouldn't be sending a HAO until it establishes a binding, thus there shouldn't be a possibility for missynchronization there either. What am I missing? Mike gabriel montenegro writes: > This is an attempt to close issue 53 in the MIPv6 draft > ("HAO keyword"): > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue53.txt > > We're cross-posting to both IPv6 and MobileIP as this concerns both lists. > I'm sending this on behalf of Jari Arkko and the Mobile IP chairs. Please > send any issues to the lists. > > tnx, > > -gabriel > -------------------------------------------------------------- > In July we had a big discussion around the right keyword for the > Home Address destination option support in IPv6 nodes. This e-mail > reviews the issue and makes a recommendation. > > Unless otherwise specified, section numbers refer to rev 18 > of the draft: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt > > BACKGROUND > > In the new security design for Mobile IPv6 (adopted to the > base specification over the course of the last year), we > allow two modes of operation for communicating with the > correspondent nodes: > > 1. Tunneling via the home agent (also called "reverse tunneling" in > section 11.2.1). > 2. Route Optimization (also called "direct delivery" in section 11.2.1): > routing directly from the mobile node to the correspondent > node (using a "home address option"), and from the > correspondent node to the mobile node (using a "routing > header - type 2"). > > Note that tunneling happens in *both* directions and that optimal > routing can *only* be performed if a binding cache entry has > been established. The mobile node can't send a packet directly to > the correspondent node until it has completed return routability > procedure and sent a binding update. This is a change from previous > versions of the protocol and was done in order to guard against > certain reflection attacks. (But see below for a special case.) > > The return routability procedure and binding updates are carried > by the Mobility Header protocol (a new IPv6 protocol). According > to RFC 2463, any node that doesn't recognize a specific "next header" > protocol value will return ICMP Parameter Problem, Code 1 to the > sender. The MIPv6 specification requires that the reception of > such a message is taken as an indication that the peer does not > support Route Optimization. > > Furthermore, even nodes that support MIPv6 may decline requests > for Route Optimization due to temporary lack of resources, for > instance. This happens via an error response within the Mobility > Header protocol itself. > > The new version of MIPv6 protocol is therefore capable of operating > both with nodes that support this specification (regardless of any > temporary inability to accept requests) and with nodes that do not > support MIPv6 (such as nodes that have already been deployed). > > The current MIPv6 specification lists the benefits of route > optimization (Section 8.2) but does not state whether it is > mandatory or not for all IPv6 nodes. The plan is to leave that for > the IPv6 node requirements document to decide. > > THE PROBLEM > > Even though it does not mandate route optimization itself, the > current MIPv6 spec does mandate that two items MUST be implemented > by *all* IPv6 nodes (section 8.1): > > 1. All IPv6 nodes MUST recognize the Home Address destination > option and, > > 2. All IPv6 nodes MUST be able to return Mobility Header error > messages. > > However, several people have complained that in the current > state of IPv6 deployment, they do not wish to add new > requirements for all nodes. > > As explained above, this isn't technically necessary as the ICMP > Parameter Problems (or the lack of response) is adequate to keep > the mobile node using tunneling. No payload packets will be sent to > the wrong place, and no packets are lost. > > However, these two requirements relate to a special case > we currently allow in the specification: direct delivery from the > mobile node to the correspondent node (which uses a home address > destination option) is allowed not just when a binding exists but > also if the packets have been protected by IPsec. This constitutes > "triangular routing": whereas the mobile node can directly deliver > packets to the correspondent node by virtue of IPsec, the opposite > is not true: the reverse direction cannot be optimized if the > correspondent node does not have a binding for the mobile node. > Although allowed, triangular routing is not adequately described > in the current spec (more below). > > Note that in any case a correspondent node that doesn't support the > Home Address destination option will send ICMP Parameter Problem, > Code 2, so that the mobile node may learn the fact that this node > is of an older variant that doesn't support this option, and > continues using reverse tunneling. > > ALTERNATIVES > > The main question in the debate was to choose: > > 1. Remove the current requirements for all nodes. > 2. Keep the current requirements for all nodes. > > However, we also have some additional questions > to answer: > > - Should triangular routing (the IPsec-protected HAO) mode be a > part of the Mobile IPv6 specification, even as optional? > > - What is the right keyword for Route Optimization > support in correspondent nodes? > > - Should the MIPv6 specification state all these > requirements for IPv6 nodes, or the IPv6 node > requirements document? > > ANALYSIS > > - Mobile nodes that try to improve upon reverse tunneling > by either route optimization or triangular routing can survive > a situation where they connect to an older node with no MIPv6 > support at all. In this case they can fall back to reverse > tunneling mode which does not require any support from the > correspondent node. > > - We need to separate the technical requirements for > mandating a specific protocol function (e.g. saying that "route > optimization or some part of it is mandatory"), and more high > level requirements (e.g. saying "security is mandatory"). > > - It is likely that obtaining an IPsec security association > between a mobile node and an arbitrary correspondent node > continues to be difficult. Even if possible, it may not be > justifiable for the mobile node to either (1) obtain such a > security association (e.g. if the traffic pattern consists of > access to public web sites), or (2) obtain it and stop without > spending the negligible *additional* effort to create a binding > entry. This implies that the main modes would be reverse > tunneling and route optimization, whereas triangular routing > via the IPsec-protected HAO would be perhaps less often used. > > - The IPsec-protected HAO mode is inadequately described > in the current specification. Section 9.2.2 describes > this possibility for the correspondent node, but not > for the mobile node in 11.2.1. This can be easily fixed, > however. > > - If we removed the IPsec-protected HAO mode from the > specification along with the HAO requirement, the effect would > be that even nodes that use IPsec would have to establish a > binding before any optimization is possible. Establishing a > binding requires 1.5 roundtrips every 7 minutes. Of course, > such nodes can continue using reverse tunneling. > > Note that the establishment of the binding can take place in > parallel with the security association establishment. > > - RFC 2119 states on the use of imperatives in RFC's: "MUST only > be used where it is actually required for interoperation or > to limit behavior which has potential for causing harm (e.g., > limiting retransmisssions) For example, they must not be used > to try to impose a particular method on implementors where the > method is not required for interoperability." > > In this respect, the "MUST" keywords on HAO processing & > error message requirements do not seem necessary, as (1) > interoperability is already achieved using other mechanisms > (ICMP/lack of answer and reverse tunneling via the home agent), > and (2) for the mode that could potentially benefit from this > the difference is not catastrophic as explained in the previous > bullet. > > RECOMMENDATION > > The requirements of RFC 2119 for a "MUST" are not fulfilled in > this case: interoperability is achieved in any case. Furthermore, > it is questionable that nodes that bother to set up an > IPsec security association would not be able to afford > a much smaller amount of memory for a binding cache > entry, particularly when bidirectionally optimal routing > can only be achieved with Route Optimization. > > Therefore, we recommend that the HAO processing and error message > MUST requirements be removed for all nodes. > > Instead, we recommend that Route Optimization support > for correspondent nodes be made a SHOULD in the IPv6 node > requirements document. The ability of a correspondent node > to participate in route optimization is good for the efficient > operation of the IPv6 Internet, beneficial for robustness and > reduction of jitter and latency, and is in some cases necessary > to avoid congestion in the home network. > > We also recommend that triangular routing via the IPsec-protected > HAO processing be described in the Mobile IPv6 base specification, > and be made a SHOULD for mobile and correspondent nodes. This > includes describing how nodes can survive the situation where > the other side does not support this mode. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 1 13:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91KmWbj004804; Tue, 1 Oct 2002 13:48:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g91KmWOe004803; Tue, 1 Oct 2002 13:48:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91KmTbj004796; Tue, 1 Oct 2002 13:48:29 -0700 (PDT) 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 g91KmJPG026853; Tue, 1 Oct 2002 13:48:25 -0700 (PDT) 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 NAA27704; Tue, 1 Oct 2002 13:48:09 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A12606A901; Tue, 1 Oct 2002 23:48:00 +0300 (EEST) Message-ID: <3D9A0B62.70301@kolumbus.fi> Date: Tue, 01 Oct 2002 23:53:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Cc: gab@Sun.COM, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: MIPv6 issue: HAO keyword References: <3D99513D.3090204@sun.com> <15769.51376.605194.114670@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > On the requirement for HAO in all IPv6 nodes... is > this actually necessary? That is, if I do not > implement a binding cache (which is not a > requirment), the only processing the node would > need to do is inform the mobile node that it can > not/will not process the HAO because it's not > legal to interpret it as a home address without a > binding entry. Likewise, a MN shouldn't be sending > a HAO until it establishes a binding, thus there > shouldn't be a possibility for missynchronization > there either. Right. And that's what we are recommending. We are saying that the current HAO requirement for all nodes should be removed. CN has no clue about HAO, MN sends anyway => ICMP Par.prob. code 2 MN tries to establish RO, no CN support => ICMP Par.prob. code 1 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 Tue Oct 1 14:04:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91L4Hbj004954; Tue, 1 Oct 2002 14:04:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g91L4HmR004953; Tue, 1 Oct 2002 14:04:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91L48bj004946; Tue, 1 Oct 2002 14:04:08 -0700 (PDT) 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 g91L3xPG001355; Tue, 1 Oct 2002 14:04:10 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07974; Tue, 1 Oct 2002 15:03:54 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g91L3pIm008055; Tue, 1 Oct 2002 14:03:51 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE61915; Tue, 1 Oct 2002 13:58:14 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03506; Tue, 1 Oct 2002 14:03:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15770.3510.759801.759699@thomasm-u1.cisco.com> Date: Tue, 1 Oct 2002 14:03:50 -0700 (PDT) To: Jari Arkko Cc: Michael Thomas , gab@Sun.COM, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: MIPv6 issue: HAO keyword In-Reply-To: <3D9A0B62.70301@kolumbus.fi> References: <3D99513D.3090204@sun.com> <15769.51376.605194.114670@thomasm-u1.cisco.com> <3D9A0B62.70301@kolumbus.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko writes: > Michael Thomas wrote: > > > On the requirement for HAO in all IPv6 nodes... is > > this actually necessary? That is, if I do not > > implement a binding cache (which is not a > > requirment), the only processing the node would > > need to do is inform the mobile node that it can > > not/will not process the HAO because it's not > > legal to interpret it as a home address without a > > binding entry. Likewise, a MN shouldn't be sending > > a HAO until it establishes a binding, thus there > > shouldn't be a possibility for missynchronization > > there either. > > Right. And that's what we are recommending. We > are saying that the current HAO requirement for all > nodes should be removed. > > CN has no clue about HAO, MN sends anyway => ICMP Par.prob. code 2 > MN tries to establish RO, no CN support => ICMP Par.prob. code 1 Good. Then I'm cool with the recommendation. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 04:21:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92BLbbj007337; Wed, 2 Oct 2002 04:21:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92BLbFH007336; Wed, 2 Oct 2002 04:21:37 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92BLXbj007329 for ; Wed, 2 Oct 2002 04:21:33 -0700 (PDT) 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 g92BLbMq025975 for ; Wed, 2 Oct 2002 04:21:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07970 for ; Wed, 2 Oct 2002 05:21:28 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14742; Wed, 2 Oct 2002 07:19:29 -0400 (EDT) Message-Id: <200210021119.HAA14742@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-beloeil-ipv6-dns-resolver-option-00.txt Date: Wed, 02 Oct 2002 07:19:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Advertisement DNS resolver Option Author(s) : L. Beloeil Filename : draft-beloeil-ipv6-dns-resolver-option-00.txt Pages : 0 Date : 2002-10-1 This document defines the DNS resolver (DNSR) option used to advertise IPv6 addresses of DNS resolvers on a link. The DNSR option, which lists the IPv6 addresses of DNS resolvers that all nodes of the link may use to resolve name or address, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a link. This document specifies the process used by a host to decide how to configure the IPv6 addresses of DNS resolvers that the host could uses in IPv6 networks. This document defines the mechanism by which a node processes the DNSR option and updates valid IPv6 addresses of DNS resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-beloeil-ipv6-dns-resolver-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-1141105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-beloeil-ipv6-dns-resolver-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-1141105.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 07:37:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92Eb3bj007927; Wed, 2 Oct 2002 07:37:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92Eb2Ju007926; Wed, 2 Oct 2002 07:37:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92Eaxbj007919 for ; Wed, 2 Oct 2002 07:36:59 -0700 (PDT) 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 g92Eb3PG019283 for ; Wed, 2 Oct 2002 07:37:04 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26954 for ; Wed, 2 Oct 2002 07:36:53 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g92EXvi07972; Wed, 2 Oct 2002 10:33:58 -0400 Message-Id: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> To: Robert Elz cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: Message from Robert Elz of "Tue, 24 Sep 2002 16:59:23 +0700." <24562.1032861563@munnari.OZ.AU> Date: Wed, 02 Oct 2002 10:33:56 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, I believe we are just going to disagree on the issue you have. You seem to be saying that the addr arch document (in order to go to Draft) requires that there exist at least 2 implementations that enforce the requirement that IIDs are exactly 64 bits. That is, they MUST NOT allow IIDs of length other than 64 to be used/configured. The actual requirement that IIDs be 64 bits is not an implementation requirement (in the addressing architecture document). It is a principle that is to be followed by other documents that specify usage of the IID. The last part of Section 2.5.1 says: The details of forming interface identifiers are defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. All the other IPv6 over foo documents are consistent with addr arch in this regard. I also remain unconvinced that the wording: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. translates into a requirement that there exist implementations that disallow IIDs of length other than 64. Following this logic, I suspect one could effectively prevent just about any document from being advanced to Draft. Documents typically have a number of principles that are not testable or enforceable, or where no one would bother to actually enforce something because the actual cost is too high. Consider: > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > [...] > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. What implementations prevent a non-globally unique IPv4 address from being used here? By your logic, this requirement would need to be stricken from the document. Or: > All interfaces are required to have at least one link-local unicast > address (see section 2.8 for additional required addresses). By your logic, we have to show that there are implementations that actually enforce that. I.e, it's not enough that implementations in practice assign a LL address to an interface, we need to show that there are implementations that prevent the possibility of the interface ever operating without a LL address. This is unreasonable. As a more general case, consider a protocol that specifies behavior X. For example, protocol X must rate limit messages of type Y. Well, anyone can come along and implement protocol X over raw sockets and have it flood the network with messages of type Y violating the required rate limitingf behavior. By your reasoning, an implementation of a protocol that doesn't also prevent another implementation running over raw sockets from violoating the spec would not be compliant. In general, no implementation can ensure that the spec is not violated when viewed in this light. Popping up a level, the arguments being used are fairly legalistic (on both mine and your side). Based on some of your earlier mail messages to the WG, it would seem that your real goal here is to do away with the requirement that all IIDs be 64 bits long and in particular you would like to remove the 'u' bit from the IID. But this was discussed explicitly within the WG and there appeared to be little support for your position. It is time to advance addr arch to Draft Standard and move on. 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 Wed Oct 2 09:33:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92GXqbj008357; Wed, 2 Oct 2002 09:33:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92GXqPF008356; Wed, 2 Oct 2002 09:33:52 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92GXmbj008349 for ; Wed, 2 Oct 2002 09:33:49 -0700 (PDT) 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 g92GXrMq022008 for ; Wed, 2 Oct 2002 09:33:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00956 for ; Wed, 2 Oct 2002 10:33:48 -0600 (MDT) 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 JAA02062 for ; Wed, 2 Oct 2002 09:33:48 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g92GXlm32137 for ; Wed, 2 Oct 2002 09:33:47 -0700 X-mProtect: <200210021633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.66.85, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEJxG8T; Wed, 02 Oct 2002 09:33:45 PDT Message-ID: <3D9B1FE8.BEFF437@iprg.nokia.com> Date: Wed, 02 Oct 2002 09:33:44 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Link local address for tunnel interfaces Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is it required to have a link local address on a tunnel interface. I am implementing IPv6 in IPv6 tunnels and wanted to know whether I should install a link local address on the tunnel interface. Is there any document that talks about this ? If it is required, how should I calculate a unique link local address ? regards Mukesh -- ****************************************************************** Everything of importance has been said before, by someone who quoted it as from somebody else. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 09:35:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92GZ4bj008374; Wed, 2 Oct 2002 09:35:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92GZ4jA008373; Wed, 2 Oct 2002 09:35:04 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92GZ1bj008366 for ; Wed, 2 Oct 2002 09:35:01 -0700 (PDT) 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 g92GZ6Mq022310 for ; Wed, 2 Oct 2002 09:35:06 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01727 for ; Wed, 2 Oct 2002 10:34:58 -0600 (MDT) 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 g92GYHQ05903; Wed, 2 Oct 2002 23:34:18 +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 g92GXB703370; Wed, 2 Oct 2002 23:33:14 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> References: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Oct 2002 23:33:11 +0700 Message-ID: <3368.1033576391@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 02 Oct 2002 10:33:56 -0400 From: Thomas Narten Message-ID: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> | I believe we are just going to disagree on the issue you have. That may be, but I would hope that there is at least one member of the IESG who understands that 2026 is not just there to be disregarded when it is inconvenient. | You seem to be saying that the addr arch document (in order to go to | Draft) requires that there exist at least 2 implementations that | enforce the requirement that IIDs are exactly 64 bits. Either that, or the text that is in doc that requires that needs to be removed. Yes, that's what 2026 requires. | That is, they | MUST NOT allow IIDs of length other than 64 to be used/configured. Yes. The text quite clearly states that IIDs are required to be 64 bits. Why exactly is it that you can't find the two implementations of this that would make my argument here irrelevant? I suspect that you have tried. That would be a simple answer. It doesn't matter much what the answer is, whether the requirement is unimplementable (which I doubt, a "if (prefixlen != 64) return (EINVAL);" would be pretty easy to add...) or whether it is just that in practice, everyone believes that this is a nonsense requirement, but in any case, it is not being implemented, and hence cannot be in a DS. | The actual requirement that IIDs be 64 bits is not an implementation | requirement (in the addressing architecture document). Hmm - that's another interesting argument. But go read it again. The doc doesn't say that other specs must not define IIDs to be any other length (to which I would object, I think, or not because of the requirement itself but because I don't believe that docs should ever specify what other docs are allowed to define - it is a dumb thing to attempt in any case). What it says, quite clearly, is that the IID must always be exactly 64 bits. No restrictions upon in what contexts (just the couple of well known assumptions). If the doc wanted to set out reasons why people should only ever use 64 bit IIDs, without actually making that a requirement, that would be fine, but that is not what it is doing. It doesn't even attempt to justify the requirement, there's no rationale at all, it is simply stated. | The last part of Section 2.5.1 says: | | The details of forming interface identifiers are defined in the | appropriate "IPv6 over " specification such as "IPv6 over | Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. Yes, but that's how the IID is to be created, not now big it is to be. And in any case, that sentence is fine. | I also remain unconvinced that the wording: | | For all unicast addresses, except those that start with binary value | 000, Interface IDs are required to be 64 bits long and to be | constructed in Modified EUI-64 format. | | translates into a requirement that there exist implementations that | disallow IIDs of length other than 64. I can't see how you can avoid "are required to be 64 bits long". | Following this logic, I suspect | one could effectively prevent just about any document from being | advanced to Draft. Only ones that shouldn't be advanced. And note, all that is required to allow it to advance, is for the unimplemented feature to be removed. | Documents typically have a number of principles | that are not testable or enforceable, The ones in question here are both testable and enforceable. So, that isn't relevant. But if the WG wanted to rewrite this one as a general guideline or something, it would probably cause less problems. That is get rid of the "are required to be" language etc. | or where no one would bother to actually enforce something | because the actual cost is too high. This is exactly (one of) the case(s) where 2026 should apply. If a doc is requiring something that cannot be implemented (reasonably) then the requirement should be removed. If that isn't done, then someone who later takes the doc, knows it is a DS (or more), and hence knows that it has been fully implemented, gets the thing, and then says "OK, all of this is proved implementable, I have to implement it all", not knowing that everyone who went before knows this is a joke, and that no-one actually bothered implementing some particular part, because it is too hard, or just plain wrong, or just unwanted (not useful) in practice. This is exactly why 2026 requires at least 2 implementations of *everything*. | Consider: | | > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses | > [...] | > | 80 bits | 16 | 32 bits | | > +--------------------------------------+--------------------------+ | > |0000..............................0000|0000| IPv4 address | | > +--------------------------------------+----+---------------------+ | > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" | > must be a globally-unique IPv4 unicast address. | | What implementations prevent a non-globally unique IPv4 address from | being used here? By your logic, this requirement would need to be | stricken from the document. Yes. I had noticed that one. And yes, it should go as well. This one happens not to concern me greatly, so it isn't one I had commented on yet. Note in this case, a correct (and entirely adequate) solution would be just to reword the doc a little, to make it clear that using something other than a globally unique IPv4 address will result in undefined behaviour. That is, rather than forbidding it, just undefine it. | Or: | | > All interfaces are required to have at least one link-local unicast | > address (see section 2.8 for additional required addresses). | | By your logic, we have to show that there are implementations that | actually enforce that. Yes, absolutely. I had assumed that had been done. I know of implementations that automatically assign a LL address whenever IPv6 is enabled on an interface, precisely because of that. There is no way to get an IPv6 interface without a LL address on it. I'd assume there are at least 2 such implementations, and that that was tested in the interop report. I wasn't part of the testing, so I don't know for sure. Certainly I'd hope that *all* implementations enforce this, and that none permit an IPv6 interface to exist without a LL address. That's one of the basic IPv6 requirements, I would have thought, but for DS we only need two of them. | I.e, it's not enough that implementations in | practice assign a LL address to an interface, we need to show that | there are implementations that prevent the possibility of the | interface ever operating without a LL address. This is unreasonable. No, it isn't, it is exactly what is required. What would be the use of having the requirement there, if you couldn't count on it being implemented? If this were merely more fluff in the spec, then yes, it too should be removed. This one however, isn't. | As a more general case, consider a protocol that specifies behavior | X. For example, protocol X must rate limit messages of type Y. Well, | anyone can come along and implement protocol X over raw sockets and | have it flood the network with messages of type Y violating the | required rate limitingf behavior. By your reasoning, an | implementation of a protocol that doesn't also prevent another | implementation running over raw sockets from violoating the spec would | not be compliant. In general, no implementation can ensure that the | spec is not violated when viewed in this light. Huh? What kind of logic is that? There have to be (for DS) at least two implementations of the protocol which implement the feature. How many others (for DS) exist that don't, is irrelevant (it becomes relevant when the spec is due for full std status). Here you seem to be confusing the implementation, with the system that runs the implementation. That a system can run both a conforming implementation, and a non-conforming one is interesting, but not relevant, the conforming one counts as one of the implementations that is required. If the only implementation of the protocol on the system in question was the one on raw sockets, with no rate limiting, then that couldn't count as one of the required two implementations, obviously. If there weren't two other implementations that actually implemented the rate limiting, then that would have to be removed. Note that 2026 does not require that no implementations get it wrong. For DS it just requires that (at least) 2 (independent) implementations get it right. | Popping up a level, the arguments being used are fairly legalistic (on | both mine and your side). They revolve around what 2026 requires. Yes. If that's "legalistic" then so be it. But there are very good reasons for 2026 requiring what it requires. If you want to change that, then go create yet another son of poisson WG, and we can look at a revision of it. (It would be kind of neat to have a poisson2 group (in the tradition of poised95...) created this year...) | Based on some of your earlier mail messages to the WG, it would seem | that your real goal here is to do away with the requirement that all | IIDs be 64 bits long and in particular you would like to remove the | 'u' bit from the IID. Yes. I do want to do away with both of those. Partly because they're both such nonsense requirements that no-one is implementing them, and people are configuring interfaces using IIDs that aren't 64 bits long (remember the thread, on some other list, ngtrans, or v6ops, or something I suspect) about why operators do this? | But this was discussed explicitly within the WG and there appeared | to be little support for your position. Actually no. If you go back and look at the record, I think you'll see that there was much more support for a change than for no change. Just re-read the messages and see. The best the chairs could come up with was "no consensus to change the doc". Nb: not "consensus against changing the doc." As I recall it, just about the only real opposition (actually stated on the list) to changing this came from you... (I don't know, obviously, but it is possible that the chairs then believed that they couldn't change the doc, because attempting to specify something that an IESG member doesn't like, or not to specify something that they do like, can cause a doc to get held at "discuss" in the IESG forever...) Even one of the WG chairs, in the message that started this discussion (in its most recent go around anyway) said, on the list, on Aug 4 ... Unfortunately, operators seem to be ignoring this restriction in numbering point-to-point links between routers. I have spoken to a few IPv6 operators, and it is common practice to use /125, /126 or even /127 prefixes for these links. What does this mean for us? Well, in my opinion, we don't want to standardize a restriction that we _know_ will be ignored by the folks who are deploying the software. Exactly correct. But even more than that, 2026 does not allow us to advance documents that specify things that no-one uses. But apart from that, once again, what the WG wants in this area is irrelevant. 2026 places some mandatory requirements on docs advancing through the process. If they're not met, then it wouldn't matter if the doc had 100% overwhelming consensus of the whole IETF, it still could not advance (except that most likely, no-one would point out the defect and it could just be silently ignored). | It is time to advance addr arch to Draft Standard and move on. If the IESG can convince itself that this doc has actually met the requirements for DS, as enumerated in 2026, then it can go ahead and vote for that I guess. I kind of hope that it is fairly obvious to just about anyone however that the requirements in this case are not met. I suspect that it is even obvious to you, you're just trying to find some kind of argument to allow them to be side-stepped here. Incidentally, I sent the first message on this thread to the IESG (only). Since then, it has been between us, with cc's going to both the IESG and the WG. But it has never been made clear whether in this small exchange you've been speaking on behalf of the IESG, or just making your own personal arguments. Which? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 09:58:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92Gw2bj008599; Wed, 2 Oct 2002 09:58:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92Gw2I3008598; Wed, 2 Oct 2002 09:58:02 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92Gvwbj008591 for ; Wed, 2 Oct 2002 09:57:59 -0700 (PDT) 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 g92Gw4Mq028725 for ; Wed, 2 Oct 2002 09:58:04 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15804 for ; Wed, 2 Oct 2002 10:57:58 -0600 (MDT) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g92GwEup022017 for ; Wed, 2 Oct 2002 12:58:14 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 2 Oct 2002 12:57:57 -0400 Message-ID: <3D9B262E.4080200@nc.rr.com> Date: Wed, 02 Oct 2002 13:00:30 -0400 From: Brian Haberman Organization: Caspian Networks 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: ipng@sunroof.eng.sun.com Subject: Re: Link local address for tunnel interfaces References: <3D9B1FE8.BEFF437@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh Gupta wrote: > Hi, > > Is it required to have a link local address on a tunnel interface. I am > implementing IPv6 in IPv6 tunnels and wanted to know whether I should > install a link local address on the tunnel interface. Is there any > document that talks about this ? RFC 2373, Section 2.8 requires that a node recognize itself by "Its Link-Local Address for each interface". That would include any virtual interfaces created by a tunnel. > > If it is required, how should I calculate a unique link local address ? Appendix A of 2373 discusses creating EUI-64 identifiers which can be used in the creation of link-local addresses. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 09:59:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92GxGbj008631; Wed, 2 Oct 2002 09:59:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92GxGC4008630; Wed, 2 Oct 2002 09:59:16 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92GxCbj008623 for ; Wed, 2 Oct 2002 09:59:12 -0700 (PDT) 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 g92GxHMq029023 for ; Wed, 2 Oct 2002 09:59:17 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04963 for ; Wed, 2 Oct 2002 10:59:11 -0600 (MDT) 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 g92GwSQ06456; Wed, 2 Oct 2002 23:58:29 +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 g92GvJ703760; Wed, 2 Oct 2002 23:57:21 +0700 (ICT) From: Robert Elz To: Mukesh Gupta cc: ipng@sunroof.eng.sun.com Subject: Re: Link local address for tunnel interfaces In-Reply-To: <3D9B1FE8.BEFF437@iprg.nokia.com> References: <3D9B1FE8.BEFF437@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Oct 2002 23:57:19 +0700 Message-ID: <3758.1033577839@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 02 Oct 2002 09:33:44 -0700 From: Mukesh Gupta Message-ID: <3D9B1FE8.BEFF437@iprg.nokia.com> | Is it required to have a link local address on a tunnel interface. I am | implementing IPv6 in IPv6 tunnels and wanted to know whether I should | install a link local address on the tunnel interface. Is there any | document that talks about this ? Yes, the addr arch doc requires LL addresses on every interface (and that includes tunnels). | If it is required, how should I calculate a unique link local address ? However you like I think. But one common method is to use the underlying tunnel address to form the IID. For v6 in v6, you could use the IID of the underlying v6 interface (or any v6 interface). Or the low N bits of that where N is 128 - the prefix length of the tunnel. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 10:20:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92HKCbj008900; Wed, 2 Oct 2002 10:20:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92HKCpM008899; Wed, 2 Oct 2002 10:20:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92HK9bj008892 for ; Wed, 2 Oct 2002 10:20:09 -0700 (PDT) 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 g92HKEPG028667 for ; Wed, 2 Oct 2002 10:20:15 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20882 for ; Wed, 2 Oct 2002 11:20:06 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g92HHst03898; Wed, 2 Oct 2002 13:17:55 -0400 Message-Id: <200210021717.g92HHst03898@cichlid.adsl.duke.edu> To: Robert Elz cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: Message from Robert Elz of "Wed, 02 Oct 2002 23:33:11 +0700." <3368.1033576391@munnari.OZ.AU> Date: Wed, 02 Oct 2002 13:17:53 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, > Actually no. If you go back and look at the record, I think you'll see > that there was much more support for a change than for no change. Just > re-read the messages and see. The best the chairs could come up with > was "no consensus to change the doc". Nb: not "consensus against > changing the doc." As I recall it, just about the only real opposition > (actually stated on the list) to changing this came from you... > (I don't know, obviously, but it is possible that the chairs then > believed that they couldn't change the doc, because attempting to specify > something that an IESG member doesn't like, or not to specify something > that they do like, can cause a doc to get held at "discuss" in the IESG > forever...) If you believe there is some sort of process problem here, there are appropriate channels for raising such issues. Wondering whether there may be an issue here while at the same time not actually raising the issue is not helpful, IMO. > Incidentally, I sent the first message on this thread to the IESG (only). > Since then, it has been between us, with cc's going to both the IESG > and the WG. But it has never been made clear whether in this small > exchange you've been speaking on behalf of the IESG, or just making > your own personal arguments. Which? To be clear, I'm speaking for myself, as one of the INT ADs, and the Area Advisor for this WG in particular. The other ADs, who have been cc'ed on this thread, will form their own opinions I'm sure. I chose to cc my original response to your note back to the ipng mailing list as a small step in having the IESG be more transparent. 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 Wed Oct 2 10:43:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92Hhwbj009083; Wed, 2 Oct 2002 10:43:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92Hhw5Q009082; Wed, 2 Oct 2002 10:43:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92Hhobj009075 for ; Wed, 2 Oct 2002 10:43:50 -0700 (PDT) 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 g92HhcPG004775 for ; Wed, 2 Oct 2002 10:43:43 -0700 (PDT) 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 LAA22897 for ; Wed, 2 Oct 2002 11:43:32 -0600 (MDT) Received: from kenawang.windriver.com ([128.224.4.101]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA26733; Wed, 2 Oct 2002 10:42:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20021002133041.03120aa0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 Oct 2002 13:43:10 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Thomas Narten , iesg@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: <3368.1033576391@munnari.OZ.AU> References: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >(I don't know, obviously, but it is possible that the chairs then >believed that they couldn't change the doc, because attempting to specify >something that an IESG member doesn't like, or not to specify something >that they do like, can cause a doc to get held at "discuss" in the IESG >forever...) This is not the case, at all... >Even one of the WG chairs, in the message that started this discussion >(in its most recent go around anyway) said, on the list, on Aug 4 ... Yes. I expressed a personal technical opinion (which I still hold). But, there was not sufficient support for my opinion on the WG mailing list to constitute a consensus to make a change to the document. I accepted that fact, and the change was not made. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 11:33:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92IXMbj009644; Wed, 2 Oct 2002 11:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92IXMmj009643; Wed, 2 Oct 2002 11:33:22 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92IXIbj009636 for ; Wed, 2 Oct 2002 11:33:18 -0700 (PDT) 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 g92IXMMq029385 for ; Wed, 2 Oct 2002 11:33:22 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15261 for ; Wed, 2 Oct 2002 12:33:17 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H3D00IBXA7FRE@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 02 Oct 2002 12:33:16 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H3D00DE6A7DRJ@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 02 Oct 2002 12:33:14 -0600 (MDT) Date: Wed, 02 Oct 2002 11:33:26 -0700 From: Alain Durand Subject: draft-ietf-ipv6-dns-discovery-06.txt To: ipng@sunroof.eng.sun.com, Bob Hinden , mrw@windriver.com, deering@cisco.com Message-id: <70D1180B-D635-11D6-8533-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear wg chairs, draft-ietf-ipv6-dns-discovery-06.txt has been published on Sept. 20th to answer comments raised on the -05 revision. No other comments have been raised in the mailing list so far. The document authors would like to request a working group last call on this new revision. - Alain, on behalf of the draft-ietf-ipv6-dns-discovery-06 authors. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 13:29:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92KTtbj010125; Wed, 2 Oct 2002 13:29:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92KTtDR010124; Wed, 2 Oct 2002 13:29:55 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92KTqbj010117 for ; Wed, 2 Oct 2002 13:29:52 -0700 (PDT) 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 g92KTvMq005072 for ; Wed, 2 Oct 2002 13:29:57 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20426 for ; Wed, 2 Oct 2002 14:29:51 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7D2E72562 for ; Wed, 2 Oct 2002 13:29:51 -0700 (PDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 99E9610B2 for ; Wed, 2 Oct 2002 13:29:50 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g92KTnw0002049299; Wed, 2 Oct 2002 16:29:50 -0400 (EDT) Date: Wed, 2 Oct 2002 16:29:50 -0400 (EDT) From: Jack McCann Message-Id: <200210022029.g92KTnw0002049299@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: >I'm asking about the second. I wonder, for example, whether someone >familiar with the POSIX/Austin Group work has reviewed the document. >My concern is that there may be some fairly trivial inconsistencies >with this document and the basic API. It would be nice to try and fix >those (if they exist). Can anyone speak to this point? So I took a look at 2292bis-07. Please note I am not speaking on behalf of posix/austin group, but rather simply as someone who has been witness to the standardization efforts there. I reviewed primarily for alignment with 2553bis and the latest posix/austin standard. I did not review, for example, correctness of constant values and data structures for match against IPv6 protocol RFCs (hopefully there have already been enough eyes that have done that). Some comments for alignment with the latest POSIX standard: - I suggest you update the Posix references, using the same reference as 2553bis, which I show below (note the spec has now also been approved by ISO): IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX) Open Group Technical Standard: Base Specifications, Issue 6 December 2001 ISO/IEC 9945-1:2002, 9945-2:2002, 9945-3:2002, 9945-4:2002 Information technology -- Portable Operating System Interface (POSIX) -- Parts 1, 2, 3 and 4 http://www.opengroup.org/austin - protocol family constants (PF_xxx) are not defined in this latest POSIX standard, replace all PF_xxx with AF_xxx (e.g. PF_INET -> AF_INET) - section 21.1 shows msg_iovlen as type size_t, the latest POSIX defines msg_iovlen as type int Some editorial comments: - section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see the nice diagram on page 67, an "ancillary data object" includes the padding at the end) "When the application uses ancillary data it must pass the returned length to CMSG_LEN() to determine how much memory is needed for the ancillary data object (including the cmsghdr structure)." - section 8 typo in first paragraph last sentence "Hob-by-Hop" - section 10.5 inet6_opt_next, the statement "Typep points the option type field" does not seem right, for typep to point to the option type field, it would have to be passed as 'uint8_t **typep'; I think you mean it points to a buffer into which the option type is stored, or using wording similar to lenp, "typep stores the option type" - section 11.1 you should cite one or more references upon which this statement is based: "Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided by default." - the data type usage in the example code could be cleaner, for example in section 22 page 72: int extlen; int cmsglen; extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); cmsglen = CMSG_SPACE(extlen); inet6_rth_space() returns a size_t into int extlen. int extlen is passed to CMSG_SPACE which expects unsigned int. CMSG_SPACE returns unsigned int into int cmsglen. and so on. A minor technical comment: - There is an inconsistency in the inet6_opt_set_val and inet6_opt_get_val functions. In both functions, the offset argument is type size_t, but the function return value (also an offset) is type int. Given the intended usage of these functions, where the return value of one call can be used as the offset argument on the next call, the data type of the offset argument should be type int. I also want to point out an issue that might be raised if this API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for standardization. The functions and macros listed below use a variety of data types for things that represent a "size", including int, unsigned int, and size_t. All these items, or at least those of type size_t, could instead be of type socklen_t. Note that some of the items identified are for use with msg_controllen and cmsg_len, which are type socklen_t. Here is the rationale for socklen_t from the latest POSIX standard: The type socklen_t was invented to cover the range of implementations seen in the field. The intent of socklen_t is to be the type for all lengths that are naturally bounded in size; that is, that they are the length of a buffer which cannot sensibly become of massive size: network addresses, host names, string representations of these, ancillary data, control messages, and socket options are examples. Truly boundless sizes are represented by size_t as in read(), write(), and so on. All socklen_t types were originally (in BSD UNIX) of type int. During the development of IEEE Std 1003.1-2001, it was decided to change all buffer lengths to size_t, which appears at face value to make sense. When dual mode 32/64-bit systems came along, this choice unnecessarily complicated system interfaces because size_t (with long) was a different size under ILP32 and LP64 models. Reverting to int would have happened except that some implementations had already shipped 64-bit-only interfaces. The compromise was a type which could be defined to be any size by the implementation: socklen_t. The following items could be of type socklen_t: - inet6_rth_space - return type - inet6_rth_init - bp_len argument - inet6_opt_init - return type (but what about error return?) - extlen argument - inet6_opt_append - return type (but what about error return?) - extlen, prevlen, len arguments - inet6_opt_finish - return type (but what about error return?) - extlen, prevlen arguments - inet6_opt_set_val - return type - offset, vallen arguments - inet6_opt_next - return type - extlen, prevlen, lenp arguments - inet6_opt_find - return type - extlen, prevlen, lenp arguments - inet6_opt_get_val - return type - offset, vallen arguments - CMSG_SPACE - return type could be socklen_t to match msg_controllen - argument type could also be socklen_t - CMSG_LEN - return type could be socklen_t to match cmsg_len type - argument type could also be socklen_t Short of a changing all of these to socklen_t, we should at least consider changing the occurances of the size_t type to either socklen_t or int or unsigned int. This would avoid the complications raised by size_t on systems having to support both ILP32 and LP64 models. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 14:01:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92L1Bbj010438; Wed, 2 Oct 2002 14:01:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92L1Buu010437; Wed, 2 Oct 2002 14:01:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92L18bj010427 for ; Wed, 2 Oct 2002 14:01:08 -0700 (PDT) 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 g92L1DPG029577 for ; Wed, 2 Oct 2002 14:01:13 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19435 for ; Wed, 2 Oct 2002 14:01:08 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D003418E6 for ; Wed, 2 Oct 2002 17:01:06 -0400 (EDT) Date: Wed, 02 Oct 2002 17:01:06 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021002210106.D003418E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I made the mistake of allowing my arm to be twisted into reviewing draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find what appears to be an ambiguity in some of text that deals with subnet-scope multicast. Given that this document was already before the IESG at the time I found this, I've been discussing this with our AD, who brought in our WG chairs once he and I agreed that there might be a problem here, but we felt that the discussion of what to do about this really should take place out in the open on the WG mailing list. So, what I said (after some initial clarifying discussion) was: In the absence of a precise definition of the distinction between a link and a subnet, it is unclear what a router should do with a packet addressed to a transient multicast address with subnet-local scope. Excerpting from the draft: 2 link-local scope 3 subnet-local scope 4 admin-local scope ... link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. So subnet-local is a larger scope than link-local, and may be derived automatically from physical connectivity (in some completely unspecified way!). So what should a router do with that packet? To forward or not to forward, that is the question. One could address this concern by adding text (somewhere) to the effect that, until such time as a standards track document specifies how a router should determine what the subnet-scope boundaries are and what a router should do with an otherwise valid packet addressed to a multicast address with scop set to subnet-local, routers should handle such packets precisely as they would if scop were set to link-local. Or something like that. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 14:10:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92LAXbj010556; Wed, 2 Oct 2002 14:10:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92LAXrS010555; Wed, 2 Oct 2002 14:10:33 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92LAUbj010548 for ; Wed, 2 Oct 2002 14:10:30 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g92LAZhe335705; Wed, 2 Oct 2002 14:10:35 -0700 (PDT) Date: Wed, 2 Oct 2002 14:10:35 -0700 From: Michael Hunter To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member Message-Id: <20021002141035.6a15351d.michael.hunter@eng.sun.com> In-Reply-To: References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> <20020925135258.3861fa68.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 26 Sep 2002 13:03:53 +0900 JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Wed, 25 Sep 2002 13:52:58 -0700, > >>>>> Michael Hunter said: [4 people's opinions about ip6r0_addr] > (correct me if I'm wrong or miss someone.) That is as I read it. [...] > > [...] > >> Another thought: most user applications are expected to use > >> inet6_rth_xxx functions, instead of directly getting access to the > >> address part following the rthdr[0] structure. Thus, either 1 nor 2 > >> affects the typical user applications. > > > So why create incompatibilities with 2292 if you expect the feature > > being broken to be used less in the future? Whats the gain? > > See Vlad's response. So the gain was: 1) it would make it more consistent with the rest of the API 2) it makes handling a corner case cleaner I personally don't see these as a strong enough reason to break the API. I strongly disgree with Vlan'd comment that "Additionally 2292bis has some other incompatibilities with 2292 this one being the least of the problems. So that argument doesn't fly." Thats a slippery slope leading you to completely abandoning backwards compatability. You should have strong technical reasons for each and every breakage of the API independent of what else you have broken. [...] > Additionally, I suspect the removal actually breaks user code so much. > As I said before, user applications are usually expected to use > library functions for source routing and to not use the ip6r0_addr > member directly. In fact, we, the KAME project, do not use the member > name in about 80 IPv6 applications we provide. I also searched on I think this is overstating your case. This is the advanced API. You don't expect it to be used in many of you applications. The real point is that you don't use it in the less then 5 (ping, telnet, traceroute, 'sniffer') applictions that might need it. > recent source code of FreeBSD and NetBSD (which have not supported > 2292bis yet). The only occurrence of ip6r0_addr other than in user > applications is in tcpdump, where no compatibility issue exists since > tcpdump uses its own header definitions. Which is telling about the stability and widespread acceptance of this API. I think its very likely that one of the reasons they needed private headers had to do with the variations of API between 2292 and 2292bis. [...] > I understand your frustration, but I'm afraid no one can "win" in this > kind of discussion. We just need a compromise, and I hope you kindly > allow us to go with the current definition. [...] I agree on this point. I'm tired. I'm done. This just isn't THAT important. Note my "frustration" and go on. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 14:38:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92LcMbj010722; Wed, 2 Oct 2002 14:38:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92LcMbJ010721; Wed, 2 Oct 2002 14:38:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92LcJbj010714 for ; Wed, 2 Oct 2002 14:38:19 -0700 (PDT) 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 g92LcMPG010039 for ; Wed, 2 Oct 2002 14:38:23 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26601 for ; Wed, 2 Oct 2002 15:38:17 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g92Lc5ih017232; Wed, 2 Oct 2002 17:38:06 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 2 Oct 2002 17:38:14 -0400 Message-ID: <3D9B66A8.57B1DD52@nc.rr.com> Date: Wed, 02 Oct 2002 17:35:37 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Austein CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, The subnet-scope is delineated in the same manner as the scopes 6,7,8,9... That is, a router maintains a scope zone id per interface. So, if I have a router that has interfaces 1,2,3, & 4 and the admin assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, then 2 and 4 are in the same subnet scope zone and multicast packets received on one of those interfaces can only be sent to the other interface with the same scope zone id. This is discussed in the Scoped Addressing Architecture in the routing section. Brian Rob Austein wrote: > > I made the mistake of allowing my arm to be twisted into reviewing > draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find > what appears to be an ambiguity in some of text that deals with > subnet-scope multicast. Given that this document was already before > the IESG at the time I found this, I've been discussing this with our > AD, who brought in our WG chairs once he and I agreed that there might > be a problem here, but we felt that the discussion of what to do about > this really should take place out in the open on the WG mailing list. > > So, what I said (after some initial clarifying discussion) was: > > In the absence of a precise definition of the distinction between a > link and a subnet, it is unclear what a router should do with a packet > addressed to a transient multicast address with subnet-local scope. > Excerpting from the draft: > > 2 link-local scope > 3 subnet-local scope > 4 admin-local scope > > ... > > link-local and site-local multicast scopes span the same > topological regions as the corresponding unicast scopes. > > subnet-local scope is given a different and larger value > than link-local to enable possible support for subnets > that span multiple links. > > admin-local scope is the smallest scope that must be > administratively configured, i.e., not automatically > derived from physical connectivity or other, non- > multicast-related configuration. > > So subnet-local is a larger scope than link-local, and may be derived > automatically from physical connectivity (in some completely > unspecified way!). So what should a router do with that packet? To > forward or not to forward, that is the question. > > One could address this concern by adding text (somewhere) to the > effect that, until such time as a standards track document specifies > how a router should determine what the subnet-scope boundaries are and > what a router should do with an otherwise valid packet addressed to a > multicast address with scop set to subnet-local, routers should handle > such packets precisely as they would if scop were set to link-local. > Or something like that. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 2 15:07:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92M7dbj010837; Wed, 2 Oct 2002 15:07:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92M7dsl010836; Wed, 2 Oct 2002 15:07:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92M7abj010829 for ; Wed, 2 Oct 2002 15:07:36 -0700 (PDT) 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 g92M7ePG017759 for ; Wed, 2 Oct 2002 15:07:40 -0700 (PDT) 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 PAA00041 for ; Wed, 2 Oct 2002 15:07:35 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g92M7QaW024381; Wed, 2 Oct 2002 15:07:26 -0700 (PDT) Received: from [171.71.119.37] (dhcp-171-71-119-37.cisco.com [171.71.119.37]) by mira-sjcd-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ACQ92368; Wed, 2 Oct 2002 15:05:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20021002210106.D003418E6@thrintun.hactrn.net> References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Date: Wed, 2 Oct 2002 15:07:55 -0700 To: Rob Austein From: Steve Deering Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:01 PM -0400 10/2/02, Rob Austein wrote: >I made the mistake of allowing my arm to be twisted into reviewing >draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find >what appears to be an ambiguity in some of text that deals with >subnet-scope multicast. Given that this document was already before >the IESG at the time I found this, I've been discussing this with our >AD, who brought in our WG chairs once he and I agreed that there might >be a problem here, but we felt that the discussion of what to do about >this really should take place out in the open on the WG mailing list. As part of the AD/chair discussion, I responded to Thomas's report of the issue as follows: >To: Thomas Narten >From: Steve Deering >Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt >Cc: Bob Hinden , Margaret Wasserman , Rob Austein , Erik Nordmark > >At 10:43 AM -0400 10/2/02, Thomas Narten wrote: >>One last (??) issue on this document has popped up. The issue as I >>understand it is that with the addition of subnet-local multicast >>scope, the document leaves out details about how routers are supposed >>to know what the actual subnet boundaries are. > >Thomas, > >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces >belong to (or, more accurately, what subnet numbers are assigned to >the links to which it has interfaces). That is the most basic >configuration info provided to a router -- it is provided with that info >in order to do unicast routing and forwarding. To enforce subnet-local >scope it is necessary simply to inhibit the forwarding of subnet-local- >destined packets between interfaces that do not belong to the same subnet. >I would have thought that would be obvious. For those for whom it is not >obvious, there is additional detail on the default configuration of >scope zone boundaries in the scoped address architecture spec, along >with lots of other info required to implement address scoping. > >More comments in-line below... > >>Rob Austein writes: >> >> > ... Excerpting from the draft: >> >> > 2 link-local scope >> > 3 subnet-local scope >> > 4 admin-local scope >> >> > ... >> >> > link-local and site-local multicast scopes span the same >> > topological regions as the corresponding unicast scopes. >> >> > subnet-local scope is given a different and larger value >> > than link-local to enable possible support for subnets >> > that span multiple links. >> >> > admin-local scope is the smallest scope that must be >> > administratively configured, i.e., not automatically >> > derived from physical connectivity or other, non- >> > multicast-related configuration. > >Note that the determination of the span of subnet-scope is an example of >"automatic derivation from...other, non-multicast related configuration", >as mentioned in the description of admin-local. > >>Here is a suggestion: >> >>1) change the wording of the subnet-local definition to say something >> like: >> >> subnet-local scope is given a different and larger value >> than link-local to enable possible support for subnets >> that span multiple links. By default, routers assume >> that subnet scope and link-local scope are equivalent. > >I think that such a change is unwarranted if it will mean even >more delay in the approval and publication of the spec. If you can >handle it as a Note to the RFC Editor or something like that, then >fine. However, I have a few problems with your added sentence >above: > > - it's odd to stick that little implementation note there in the > middle of the scope descriptions > > - it should refer to nodes, not just routers > > - your statement would not necessarily be true for routers that do > support multi-link subnets -- for the them, the default might be > *not* to assume that subnet-local and link-local scope are > equivalent. > >Here's an alternative to your sentence which bypasses those problems: > > In the normal case of a subnet confined to a single link, > subnet-scope is equivalent to link-scope. > >>2) to the admin-local scope, tweak the wording to say something like: >> >> admin-local and all larger scopes must be >> administratively configured, i.e., they are not >> automatically derived from physical connectivity or >> other, non-multicast-related configuration. >> >>Make sense? > >I don't object to that changed wording, but neither do I see the >necessity of it. > >Steve In a response to that message, Rob asked me if I had forgotten about unnumbered point-to-point links. I answered as follows: >Yes, I did forget about them, but I think it's obvious how to handle them: >they are not part of a subnet that exists on any other link, so subnet- >scope multicasts would not be forwarded to or from an unnumbered link. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 15:07:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92M7wbj010847; Wed, 2 Oct 2002 15:07:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92M7vVc010846; Wed, 2 Oct 2002 15:07:57 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92M7rbj010839 for ; Wed, 2 Oct 2002 15:07:53 -0700 (PDT) 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 g92M7vMq000095 for ; Wed, 2 Oct 2002 15:07:58 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18143 for ; Wed, 2 Oct 2002 16:07:52 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6189918AE for ; Wed, 2 Oct 2002 18:07:51 -0400 (EDT) Date: Wed, 02 Oct 2002 18:07:51 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <3D9B66A8.57B1DD52@nc.rr.com> References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <3D9B66A8.57B1DD52@nc.rr.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021002220751.6189918AE@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote: > > The subnet-scope is delineated in the same manner as the scopes > 6,7,8,9... That is, a router maintains a scope zone id per interface. > So, if I have a router that has interfaces 1,2,3, & 4 and the admin > assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, > then 2 and 4 are in the same subnet scope zone and multicast packets > received on one of those interfaces can only be sent to the other > interface with the same scope zone id. The key phrase in your explanation is "the admin assigns". The addr-arch doc says "admin-local scope is the smallest scope that must be administratively configured". So which is 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 Oct 2 15:11:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92MBUbj010898; Wed, 2 Oct 2002 15:11:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92MBUBj010897; Wed, 2 Oct 2002 15:11:30 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g92MBRbj010890 for ; Wed, 2 Oct 2002 15:11:27 -0700 (PDT) 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 g92MBVMq000910 for ; Wed, 2 Oct 2002 15:11:31 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03726 for ; Wed, 2 Oct 2002 16:11:26 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4056118AE for ; Wed, 2 Oct 2002 18:11:25 -0400 (EDT) Date: Wed, 02 Oct 2002 18:11:25 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021002221125.4056118AE@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: > > In a response to that message, Rob asked me if I had forgotten about > unnumbered point-to-point links. I answered as follows: > > >Yes, I did forget about them, but I think it's obvious how to handle them: > >they are not part of a subnet that exists on any other link, so subnet- > >scope multicasts would not be forwarded to or from an unnumbered link. Assuming that one suspends disbelief about the whole multi-link subnet thing in the first place, it's far from obvious to me that unnumbered links aren't part of a subnet that exists on other links. The most common use I've seen of proxy ARP in IPv4 has been to extrude small numbers of IP addresses across PPP links. My apologies for not answering the rest of Steve's message right now, but my family is about to break down the door to my office because they want to eat dinner now.... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 15:55:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92MtYbj011103; Wed, 2 Oct 2002 15:55:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92MtYU4011102; Wed, 2 Oct 2002 15:55:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92MtVbj011095 for ; Wed, 2 Oct 2002 15:55:31 -0700 (PDT) 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 g92MtaPG000942 for ; Wed, 2 Oct 2002 15:55:36 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09475 for ; Wed, 2 Oct 2002 15:55:30 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g92MtMaW022346; Wed, 2 Oct 2002 15:55:22 -0700 (PDT) Received: from [171.71.119.37] (dhcp-171-71-119-37.cisco.com [171.71.119.37]) by mira-sjcd-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ACQ94163; Wed, 2 Oct 2002 15:53:33 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20021002221125.4056118AE@thrintun.hactrn.net> References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <20021002221125.4056118AE@thrintun.hactrn.net> Date: Wed, 2 Oct 2002 15:55:51 -0700 To: Rob Austein From: Steve Deering Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:11 PM -0400 10/2/02, Rob Austein wrote: >At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: > > > > In a response to that message, Rob asked me if I had forgotten about > > unnumbered point-to-point links. I answered as follows: > > > > >Yes, I did forget about them, but I think it's obvious how to handle them: > > >they are not part of a subnet that exists on any other link, so subnet- > > >scope multicasts would not be forwarded to or from an unnumbered link. > >Assuming that one suspends disbelief about the whole multi-link subnet >thing in the first place, it's far from obvious to me that unnumbered >links aren't part of a subnet that exists on other links. So which is it? Either we're talking about the case where multilink subnets are not employed (no need to believe in them), in which case my statement holds. Or we are venturing into the oh-so-scary land of multilink subnets, in which case the routers know (are required to know, in order to make unicast routing work) that they are extending the span of a subnet across more than one link, possibly including point-to-point links, so know which links are part of the same subnet, and can therefore do subnet-scope boundary enforcement as necessary. What am I missing here? >The most common use I've seen of proxy ARP in IPv4 has been to extrude >small numbers of IP addresses across PPP links. Yes, proxy ARP is an (undocumented) special case of multilink subnetting. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 16:08:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92N8Hbj011202; Wed, 2 Oct 2002 16:08:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g92N8HlX011201; Wed, 2 Oct 2002 16:08:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g92N8Ebj011194 for ; Wed, 2 Oct 2002 16:08:14 -0700 (PDT) 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 g92N8IPG005066 for ; Wed, 2 Oct 2002 16:08:19 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15289 for ; Wed, 2 Oct 2002 17:08:13 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g92N85aW003432; Wed, 2 Oct 2002 16:08:05 -0700 (PDT) Received: from [171.71.119.37] (dhcp-171-71-119-37.cisco.com [171.71.119.37]) by mira-sjcd-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ACQ94598; Wed, 2 Oct 2002 16:06:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20021002220751.6189918AE@thrintun.hactrn.net> References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <3D9B66A8.57B1DD52@nc.rr.com> <20021002220751.6189918AE@thrintun.hactrn.net> Date: Wed, 2 Oct 2002 16:08:34 -0700 To: Rob Austein From: Steve Deering Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:07 PM -0400 10/2/02, Rob Austein wrote: >The key phrase in your explanation is "the admin assigns". The >addr-arch doc says "admin-local scope is the smallest scope that must >be administratively configured". So which is it? You omitted the full description: admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. Subnet-local scope is an example of automatic derivation from "other, non-multicast-related configuration". Specifically, you don't directly configure a router to know which subnet-scope boundaries pass through it (as you must do with larger scopes). Rather, you (typically, manually) configure the router with subnet info -- including, perhaps, enabling or disabling multilink-subnet behavior -- as required for unicast routing, and then you automatically derive subnet-scope boundary information from that "other, non-multicast-related configuration". Or saying it more concisely: you don't administratively configure subnet scope; you adminstratively configure subnet info for unicast purposes, and then automatically derive subnet scope from that. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 18:42:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g931gwbj011542; Wed, 2 Oct 2002 18:42:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g931gvc3011541; Wed, 2 Oct 2002 18:42:57 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g931gsbj011534 for ; Wed, 2 Oct 2002 18:42:54 -0700 (PDT) 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 g931gxMq028286 for ; Wed, 2 Oct 2002 18:42:59 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19294 for ; Wed, 2 Oct 2002 18:42:53 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2D85118E6 for ; Wed, 2 Oct 2002 21:42:52 -0400 (EDT) Date: Wed, 02 Oct 2002 21:42:52 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <3D9B66A8.57B1DD52@nc.rr.com> <20021002220751.6189918AE@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021003014252.2D85118E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 2 Oct 2002 16:08:34 -0700, Steve Deering wrote: > > At 6:07 PM -0400 10/2/02, Rob Austein wrote: > >The key phrase in your explanation is "the admin assigns". The > >addr-arch doc says "admin-local scope is the smallest scope that must > >be administratively configured". So which is it? > > You omitted the full description: > > admin-local scope is the smallest scope that must be > administratively configured, i.e., not automatically > derived from physical connectivity or other, non- > multicast-related configuration. > > Subnet-local scope is an example of automatic derivation from "other, > non-multicast-related configuration". ^ administrative > Specifically, you don't directly configure a router to know which > subnet-scope boundaries pass through it (as you must do with larger > scopes). Rather, you (typically, manually) configure the router > with subnet info -- including, perhaps, enabling or disabling > multilink-subnet behavior -- as required for unicast routing, and > then you automatically derive subnet-scope boundary information from > that "other, non-multicast-related configuration". > > Or saying it more concisely: you don't administratively configure > subnet scope; you adminstratively configure subnet info for unicast > purposes, and then automatically derive subnet scope from that. Fine, you don't do multicast configuration, you do non-muliticast configuration and automatically derive the multicast configuration of it from the non-multicast configuration. The point, however, if you go back to my original message, is that the text in the draft can also be read as saying that the router is somehow supposed to deduce this bit of configuration from its physical connectivity without any administrative configuration at all, which is sufficiently nebulous that it could logic like "oh, I have an ethernet interface and a firewire interface, and I just know that multi-link subnets were invented to make my firewire interface happy, so set the same scope ID on both of these interfaces and forward packets between them." Which (again suspending disbelief) would arguably be ok if there were a specification for multi-link behavior that said to do that, but there isn't, so the draft leaves some ambiguity about whether certain packets should be forwarded or not. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 18:53:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g931rhbj011633; Wed, 2 Oct 2002 18:53:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g931rhmo011632; Wed, 2 Oct 2002 18:53:43 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g931rebj011625 for ; Wed, 2 Oct 2002 18:53:40 -0700 (PDT) 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 g931riMq000329 for ; Wed, 2 Oct 2002 18:53:44 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10309 for ; Wed, 2 Oct 2002 19:53:39 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g931Kqj7020509 for ; Wed, 2 Oct 2002 21:52:38 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 2 Oct 2002 21:20:53 -0400 Message-ID: <3D9B9AA0.6119AA1@nc.rr.com> Date: Wed, 02 Oct 2002 21:17:20 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <3D9B66A8.57B1DD52@nc.rr.com> <20021002220751.6189918AE@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob Austein wrote: > > At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote: > > > > The subnet-scope is delineated in the same manner as the scopes > > 6,7,8,9... That is, a router maintains a scope zone id per interface. > > So, if I have a router that has interfaces 1,2,3, & 4 and the admin > > assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, > > then 2 and 4 are in the same subnet scope zone and multicast packets > > received on one of those interfaces can only be sent to the other > > interface with the same scope zone id. > > The key phrase in your explanation is "the admin assigns". The > addr-arch doc says "admin-local scope is the smallest scope that must > be administratively configured". So which is it? Ah, I missed that addition to the text. But, the handling from a forwarding and routing point of view is the same (via the settings of the scope zone id). As for the setting of the scope zone ids. Those can be derived by the prefix configuration on each interface. If the prefixes on interfaces 2 and 4 above are the same, the scope zone id will be the same. And I believe that Steve addressed the issue of unnumbered links in a different message. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 19:14:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g932E6bj011771; Wed, 2 Oct 2002 19:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g932E6YM011770; Wed, 2 Oct 2002 19:14:06 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g932E3bj011763 for ; Wed, 2 Oct 2002 19:14:03 -0700 (PDT) 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 g932E8Mq003618 for ; Wed, 2 Oct 2002 19:14:08 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26425 for ; Wed, 2 Oct 2002 19:14:02 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7009218AE for ; Wed, 2 Oct 2002 22:14:01 -0400 (EDT) Date: Wed, 02 Oct 2002 22:14:01 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021003021401.7009218AE@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: > > >>Here is a suggestion: > >> > >>1) change the wording of the subnet-local definition to say something > >> like: > >> > >> subnet-local scope is given a different and larger value > >> than link-local to enable possible support for subnets > >> that span multiple links. By default, routers assume > >> that subnet scope and link-local scope are equivalent. > > > >I think that such a change is unwarranted if it will mean even > >more delay in the approval and publication of the spec. If you can > >handle it as a Note to the RFC Editor or something like that, then > >fine. However, I have a few problems with your added sentence > >above: > > > > - it's odd to stick that little implementation note there in the > > middle of the scope descriptions The current text of that paragraph in the addr-arch document introduces an ambiguity, so it seems like a reasonable place to try to resolve that ambiguity. > > - it should refer to nodes, not just routers Fair enough. It's the router behavior that I'm worried about, but your proposed change is both harmless and reasonable. > > - your statement would not necessarily be true for routers that do > > support multi-link subnets -- for the them, the default might be > > *not* to assume that subnet-local and link-local scope are > > equivalent. Since there is as yet no standards track definition of a multi-link subnet, this would amount to adding a normative reference that would block publication of the addr-arch Draft Standard for quite a while. I assume that nobody wants such a thing to happen (I certainly don't). > >Here's an alternative to your sentence which bypasses those problems: > > > > In the normal case of a subnet confined to a single link, > > subnet-scope is equivalent to link-scope. Same problem: in what case is a subnet not confined to a single link, and how do you describe that case without adding a normative reference? > >>2) to the admin-local scope, tweak the wording to say something like: > >> > >> admin-local and all larger scopes must be > >> administratively configured, i.e., they are not > >> automatically derived from physical connectivity or > >> other, non-multicast-related configuration. > > > >I don't object to that changed wording, but neither do I see the > >necessity of it. I think the intention here was to remove the (presumably accidental) implication that configuration for anything smaller than admin-local -could- be derived automatically from physical connectivity. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 20:40:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g933eBbj012029; Wed, 2 Oct 2002 20:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g933eBiF012028; Wed, 2 Oct 2002 20:40:11 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g933e7bj012021 for ; Wed, 2 Oct 2002 20:40:08 -0700 (PDT) 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 g933eDMq016619 for ; Wed, 2 Oct 2002 20:40:13 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21748 for ; Wed, 2 Oct 2002 21:40:07 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D17D918E6 for ; Wed, 2 Oct 2002 23:40:06 -0400 (EDT) Date: Wed, 02 Oct 2002 23:40:06 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <20021002221125.4056118AE@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021003034006.D17D918E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 2 Oct 2002 15:55:51 -0700, Steve Deering wrote: > > Either we're talking about the case where multilink subnets are not > employed (no need to believe in them), in which case my statement > holds. Right. > Or we are venturing into the oh-so-scary land of multilink subnets, > in which case the routers know (are required to know, in order to > make unicast routing work) that they are extending the span of a > subnet across more than one link, possibly including point-to-point > links, so know which links are part of the same subnet, and can > therefore do subnet-scope boundary enforcement as necessary. > > What am I missing here? A standards track specification for the latter case. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 2 23:33:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g936Xnbj012323; Wed, 2 Oct 2002 23:33:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g936XnE5012322; Wed, 2 Oct 2002 23:33:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g936XZbj012312 for ; Wed, 2 Oct 2002 23:33:45 -0700 (PDT) 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 g936XcPG019439 for ; Wed, 2 Oct 2002 23:33:38 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04964 for ; Thu, 3 Oct 2002 00:33:24 -0600 (MDT) 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 g936WWQ29080; Thu, 3 Oct 2002 13:32:35 +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 g936WJ706223; Thu, 3 Oct 2002 13:32:22 +0700 (ICT) From: Robert Elz To: Steve Deering cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Oct 2002 13:32:19 +0700 Message-ID: <6221.1033626739@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 2 Oct 2002 15:07:55 -0700 From: Steve Deering Message-ID: | >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces | >belong to (or, more accurately, what subnet numbers are assigned to | >the links to which it has interfaces). That is the most basic | >configuration info provided to a router -- it is provided with that info | >in order to do unicast routing and forwarding. To enforce subnet-local | >scope it is necessary simply to inhibit the forwarding of subnet-local- | >destined packets between interfaces that do not belong to the same subnet. If I have A --------- B --------- C and A-B is prefix1::/64 and B-C is prefix2::/64 and prefix1 != prefix2 then subnet local multicast packets are not forwarded through B, right? If I have A --------- B --------- C and A-B is prefix3::/64 and B-C is prefix3::/64 (a multi-link subnet) then subnet local multicast packets are forwarded through B, right? And if I have A --------- B --------- C And A-B is prefix1::/64 and prefix3::/64, and B-C is prefix2::/64 and prefix3::/64 (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3) then subnet local multicast packets arriving at B are ..... ??? I also assume that the necessary two implementations of all of this, that will allow a doc containing it to advance to DS have been documented in the implementation report? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 00:37:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g937bUbj012500; Thu, 3 Oct 2002 00:37:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g937bU2d012499; Thu, 3 Oct 2002 00:37:30 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g937bRbj012492 for ; Thu, 3 Oct 2002 00:37:27 -0700 (PDT) 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 g937bVMq021939 for ; Thu, 3 Oct 2002 00:37:31 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19130 for ; Thu, 3 Oct 2002 00:36:53 -0700 (PDT) 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 g937ZoQ13644; Thu, 3 Oct 2002 14:35:52 +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 g937Zc706585; Thu, 3 Oct 2002 14:35:41 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200210021717.g92HHst03898@cichlid.adsl.duke.edu> References: <200210021717.g92HHst03898@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Oct 2002 14:35:38 +0700 Message-ID: <6583.1033630538@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 02 Oct 2002 13:17:53 -0400 From: Thomas Narten Message-ID: <200210021717.g92HHst03898@cichlid.adsl.duke.edu> | If you believe there is some sort of process problem here, I didn't say that. I didn't ever say there was consensus to change things, just as no-one (other than perhaps, by implication, you in your recent message, ever claimed there was consensus not to change things). I did some idle musing, based upon experience of WG's sometimes deferring their opinion of what is technically best, to demands of the IESG. But that was never anything more than wondering. But even if I did believe there was a problem in this case, I wouldn't bother with ... | there are appropriate channels for raising such issues. because it wouldn't matter anyway. Wasting everyone's time debating process issues that simply don't matter isn't productive. Here, it doesn't matter, as whatever the WG consensus was, 2026 gives the WG (and the IESG) no choice in the matter (or not unless someone revises 2026 first). Of course, the WG can decide to recycle the doc at PS if it wants to. But so far anyway, I don't think there's been any consideration to that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 03:15:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93AFebj013123; Thu, 3 Oct 2002 03:15:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93AFe4r013122; Thu, 3 Oct 2002 03:15:40 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g93AFQbj013115 for ; Thu, 3 Oct 2002 03:15:37 -0700 (PDT) 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 g93AFUMq010532 for ; Thu, 3 Oct 2002 03:15:30 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24730 for ; Thu, 3 Oct 2002 03:15:25 -0700 (PDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Oct 2002 03:15:24 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Oct 2002 03:15:24 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 Oct 2002 03:14:51 -0700 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: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Date: Thu, 3 Oct 2002 03:14:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Thread-Index: AcJqqIWIKU3gKpH1SSSizXG2XAjzDwAHPBPA From: "Brian Zill" To: "Robert Elz" Cc: X-OriginalArrivalTime: 03 Oct 2002 10:14:51.0334 (UTC) FILETIME=[B5F09660:01C26AC5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g93AFbbj013116 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz [mailto:kre@munnari.OZ.AU] > > I also assume that the necessary two implementations of all > of this, that will allow a doc containing it to advance to DS > have been documented in the implementation report? This draft is up for PS, not DS. --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 Oct 3 03:45:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93Aj2bj013210; Thu, 3 Oct 2002 03:45:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93Aj1c6013209; Thu, 3 Oct 2002 03:45:01 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g93Aiwbj013202 for ; Thu, 3 Oct 2002 03:44:58 -0700 (PDT) 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 g93Aj2Mq014028 for ; Thu, 3 Oct 2002 03:45:02 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19536 for ; Thu, 3 Oct 2002 04:44:50 -0600 (MDT) 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 g93Ai6C03391; Thu, 3 Oct 2002 17:44:09 +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 g93Ahq707698; Thu, 3 Oct 2002 17:43:53 +0700 (ICT) From: Robert Elz To: "Brian Zill" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Oct 2002 17:43:52 +0700 Message-ID: <7696.1033641832@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 3 Oct 2002 03:14:50 -0700 From: "Brian Zill" Message-ID: | This draft is up for PS, not DS. It is entirely possible I've gotten myself confused here, but Rob Austein's message that started this thread said ... I made the mistake of allowing my arm to be twisted into reviewing draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and [...] so I just presumed that was the draft that was actually being discussed (and that one really is up for DS, not PS). It does seem to be the one that defines link-local, subnet-local, admin-local (etc) multicast scopes (as they're represented in addresses anyway). What did I miss? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 04:34:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93BYqbj013341; Thu, 3 Oct 2002 04:34:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93BYqbo013340; Thu, 3 Oct 2002 04:34:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93BYnbj013333 for ; Thu, 3 Oct 2002 04:34:49 -0700 (PDT) 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 g93BYrPG024398 for ; Thu, 3 Oct 2002 04:34:53 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10925 for ; Thu, 3 Oct 2002 05:34:44 -0600 (MDT) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g93BYYid024436 for ; Thu, 3 Oct 2002 07:34:35 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 3 Oct 2002 07:34:43 -0400 Message-ID: <3D9C2BF3.6020505@nc.rr.com> Date: Thu, 03 Oct 2002 07:37:23 -0400 From: Brian Haberman Organization: Caspian Networks 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: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <6221.1033626739@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces > | >belong to (or, more accurately, what subnet numbers are assigned to > | >the links to which it has interfaces). That is the most basic > | >configuration info provided to a router -- it is provided with that info > | >in order to do unicast routing and forwarding. To enforce subnet-local > | >scope it is necessary simply to inhibit the forwarding of subnet-local- > | >destined packets between interfaces that do not belong to the same subnet. > > > If I have > > A --------- B --------- C > > and A-B is prefix1::/64 and B-C is prefix2::/64 and prefix1 != prefix2 > then subnet local multicast packets are not forwarded through B, right? Yes. > > If I have > > A --------- B --------- C > > and A-B is prefix3::/64 and B-C is prefix3::/64 (a multi-link subnet) > then subnet local multicast packets are forwarded through B, right? Yes. > > And if I have > > A --------- B --------- C > > And A-B is prefix1::/64 and prefix3::/64, and B-C is prefix2::/64 and > prefix3::/64 (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3) > then subnet local multicast packets arriving at B are ..... ??? What is the source address of the subnet-local multicast address? Section 9, bullet 2 in the scoped addressing architecture doc describes the forwarding logic for this case. If the packet was sourced out of prefix3, it would be forwarded. If it was sourced out of one of the other prefixes, it would be dropped. 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 Oct 3 04:57:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93BvYbj013570; Thu, 3 Oct 2002 04:57:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93BvYWa013569; Thu, 3 Oct 2002 04:57:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93BvVbj013562 for ; Thu, 3 Oct 2002 04:57:31 -0700 (PDT) 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 g93BvZPG026865 for ; Thu, 3 Oct 2002 04:57:35 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25152 for ; Thu, 3 Oct 2002 05:57:30 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA05422; Thu, 3 Oct 2002 04:56:29 -0700 (PDT) Message-Id: <5.1.0.14.2.20021003075551.026c8ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 07:58:22 -0400 To: "Brian Zill" From: Margaret Wasserman Subject: RE: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: "Robert Elz" , 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 Hi Brian, Just to clarify... The subnet-local multicast scope is defined in the Addressing Architecture document, which been sent to the IESG for consideration as a draft standard. Perhaps the mention of scoping has you thinking of the scoped addressing architecture? That hasn't been sent to the IESG at all yet. Margaret At 06:14 AM 10/3/02, Brian Zill wrote: > > From: Robert Elz [mailto:kre@munnari.OZ.AU] > > > > I also assume that the necessary two implementations of all > > of this, that will allow a doc containing it to advance to DS > > have been documented in the implementation report? > >This draft is up for PS, not DS. > >--Brian > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 09:31:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93GVSbj014347; Thu, 3 Oct 2002 09:31:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93GVS56014346; Thu, 3 Oct 2002 09:31:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93GVObj014339 for ; Thu, 3 Oct 2002 09:31:24 -0700 (PDT) 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 g93GVTPG014040 for ; Thu, 3 Oct 2002 09:31:29 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09232 for ; Thu, 3 Oct 2002 10:31:23 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Oct 2002 09:31:17 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Oct 2002 09:31:17 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Oct 2002 09:31:17 -0700 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: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Date: Thu, 3 Oct 2002 09:31:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Thread-Index: AcJq1AkzwnTHgfnxSO+ctKXMOs959wAJfJrw From: "Brian Zill" To: "Margaret Wasserman" Cc: "Robert Elz" , X-OriginalArrivalTime: 03 Oct 2002 16:31:17.0552 (UTC) FILETIME=[4C5FF300:01C26AFA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g93GVPbj014340 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ah yes, sorry, I mistakeningly thought that we were discussing the scoped addressing architecture draft in the second thread. I probably shouldn't post at 3 AM. --Brian > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, October 03, 2002 04:58 > To: Brian Zill > Cc: Robert Elz; ipng@sunroof.eng.sun.com > Subject: RE: IPv6 subnet-local addresses and > draft-ietf-ipngwg-addr-arch-v3-10.txt > > > > Hi Brian, > > Just to clarify... > > The subnet-local multicast scope is defined in the Addressing > Architecture document, which been sent to the IESG for > consideration as a draft standard. > > Perhaps the mention of scoping has you thinking of the scoped > addressing architecture? That hasn't been sent to the IESG > at all yet. > > Margaret > > At 06:14 AM 10/3/02, Brian Zill wrote: > > > From: Robert Elz [mailto:kre@munnari.OZ.AU] > > > > > > I also assume that the necessary two implementations of > all of this, > > > that will allow a doc containing it to advance to DS have been > > > documented in the implementation report? > > > >This draft is up for PS, not DS. > > > >--Brian > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 10:19:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93HJ7bj014608; Thu, 3 Oct 2002 10:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93HJ7Ru014607; Thu, 3 Oct 2002 10:19:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93HJ4bj014600 for ; Thu, 3 Oct 2002 10:19:04 -0700 (PDT) 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 g93HJ9PG026365 for ; Thu, 3 Oct 2002 10:19:09 -0700 (PDT) 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 LAA07976 for ; Thu, 3 Oct 2002 11:18:49 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9A38385A for ; Thu, 3 Oct 2002 13:18:29 -0400 (EDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id B1F47BD8 for ; Thu, 3 Oct 2002 10:18:28 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g93HISt0001722042; Thu, 3 Oct 2002 13:18:28 -0400 (EDT) Date: Thu, 3 Oct 2002 13:18:28 -0400 (EDT) From: Jack McCann Message-Id: <200210031718.g93HISt0001722042@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - CMSG_SPACE > - return type could be socklen_t to match msg_controllen > - argument type could also be socklen_t > > - CMSG_LEN > - return type could be socklen_t to match cmsg_len type > - argument type could also be socklen_t > >Short of a changing all of these to socklen_t, we should at least >consider changing the occurances of the size_t type to either >socklen_t or int or unsigned int. This would avoid the complications >raised by size_t on systems having to support both ILP32 and LP64 models. Given that CMSG_SPACE and CMSG_LEN were defined in RFC 2292, and that their definitions have not changed in 2292bis, and that they do not used size_t, I'd vote for leaving them as is. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 10:54:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93Hsgbj014880; Thu, 3 Oct 2002 10:54:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g93HsgGp014879; Thu, 3 Oct 2002 10:54:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g93Hscbj014872 for ; Thu, 3 Oct 2002 10:54:38 -0700 (PDT) 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 g93HsfPG006354 for ; Thu, 3 Oct 2002 10:54:41 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00718 for ; Thu, 3 Oct 2002 11:54:32 -0600 (MDT) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g93HsMt77528; Fri, 4 Oct 2002 02:54:23 +0900 (JST) Date: Fri, 04 Oct 2002 02:54:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member In-Reply-To: <20021002141035.6a15351d.michael.hunter@eng.sun.com> References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> <20020925135258.3861fa68.michael.hunter@eng.sun.com> <20021002141035.6a15351d.michael.hunter@eng.sun.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: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 2 Oct 2002 14:10:35 -0700, >>>>> Michael Hunter said: >> Additionally, I suspect the removal actually breaks user code so much. >> As I said before, user applications are usually expected to use >> library functions for source routing and to not use the ip6r0_addr >> member directly. In fact, we, the KAME project, do not use the member >> name in about 80 IPv6 applications we provide. I also searched on > I think this is overstating your case. This is the advanced API. You > don't expect it to be used in many of you applications. The real point > is that you don't use it in the less then 5 (ping, telnet, traceroute, > 'sniffer') applictions that might need it. I admit the point. I should have raised applications that use a routing header to be fair enough. >> recent source code of FreeBSD and NetBSD (which have not supported >> 2292bis yet). The only occurrence of ip6r0_addr other than in user >> applications is in tcpdump, where no compatibility issue exists since >> tcpdump uses its own header definitions. > Which is telling about the stability and widespread acceptance of this > API. I think its very likely that one of the reasons they needed > private headers had to do with the variations of API between 2292 and > 2292bis. Actually, tcpdump uses its own header definitions in many source files. Regarding IPv6 related ones, it (re)defines the IPv6 header, the Hop-by-Hop options header, the Destination options header, the Fragment header, and the Routing header. > [...] >> I understand your frustration, but I'm afraid no one can "win" in this >> kind of discussion. We just need a compromise, and I hope you kindly >> allow us to go with the current definition. > [...] > I agree on this point. I'm tired. I'm done. This just isn't THAT > important. Note my "frustration" and go on. Okay, thanks for your kindness, and I'm sorry that I cannot be productive in this discussion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 3 19:15:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g942Ffbj015856; Thu, 3 Oct 2002 19:15:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g942Fejd015855; Thu, 3 Oct 2002 19:15:40 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g942Fabj015848 for ; Thu, 3 Oct 2002 19:15:36 -0700 (PDT) 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 g942FfMq012236 for ; Thu, 3 Oct 2002 19:15:41 -0700 (PDT) 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 TAA02871 for ; Thu, 3 Oct 2002 19:15:35 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 448644B22; Fri, 4 Oct 2002 11:15:27 +0900 (JST) To: Michael Hunter , ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Fri, 04 Oct 2002 02:54:53 +0900. 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: 2292bis ip6_rthdr0 flexible array member From: itojun@iijlab.net Date: Fri, 04 Oct 2002 11:15:27 +0900 Message-Id: <20021004021527.448644B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> recent source code of FreeBSD and NetBSD (which have not supported >>> 2292bis yet). The only occurrence of ip6r0_addr other than in user >>> applications is in tcpdump, where no compatibility issue exists since >>> tcpdump uses its own header definitions. > >> Which is telling about the stability and widespread acceptance of this >> API. I think its very likely that one of the reasons they needed >> private headers had to do with the variations of API between 2292 and >> 2292bis. > >Actually, tcpdump uses its own header definitions in many source >files. Regarding IPv6 related ones, it (re)defines the IPv6 header, >the Hop-by-Hop options header, the Destination options header, the >Fragment header, and the Routing header. this is because tcpdump would like to decode IPv6 frames even when it runs on IPv4-only platforms. the re-definition has nothing to do with the acceptance of RFC2292. 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 Fri Oct 4 00:33:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g947Xibj016275; Fri, 4 Oct 2002 00:33:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g947Xh4c016274; Fri, 4 Oct 2002 00:33:43 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g947Xdbj016267 for ; Fri, 4 Oct 2002 00:33:39 -0700 (PDT) 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 g947XhMq025473 for ; Fri, 4 Oct 2002 00:33:43 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18226 for ; Fri, 4 Oct 2002 01:33:37 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:fd1e:dbd9:fffd:5ba7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g947XPt81531; Fri, 4 Oct 2002 16:33:25 +0900 (JST) Date: Fri, 04 Oct 2002 16:34:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> References: <24562.1032861563@munnari.OZ.AU> <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> 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: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 02 Oct 2002 10:33:56 -0400, >>>>> Thomas Narten said: > You seem to be saying that the addr arch document (in order to go to > Draft) requires that there exist at least 2 implementations that > enforce the requirement that IIDs are exactly 64 bits. That is, they > MUST NOT allow IIDs of length other than 64 to be used/configured. > The actual requirement that IIDs be 64 bits is not an implementation > requirement (in the addressing architecture document). It is a > principle that is to be followed by other documents that specify usage > of the IID. The last part of Section 2.5.1 says: > The details of forming interface identifiers are defined in the > appropriate "IPv6 over " specification such as "IPv6 over > Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. > All the other IPv6 over foo documents are consistent with addr arch in > this regard. I don't want to delay the publication of the draft, but there is one thing which has always been unclear to me. So please let me ask a question. Then the "other documents" should be considered as an implementation requirement? For example, does RFC 2464 require implementations to use 64-bit interface identifiers (and prohibit using shorter or longer identifiers) on ethernet links? Also, does RFC 2374 require implementations to use 64-bit interface identifiers (and prohibit using others) for aggregatable global unicast addresses? If so (for both questions), how can we configure an aggregatable global address on a link which has an "IPv6 over foo" document requiring a different length than 64 as interface identifiers? I cannot be clear on those questions just from the specification documents. Perhaps there have been discussions on this that make the points clear, and I'd apologize in advance if so, then please give me a pointer. 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 Oct 4 08:42:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94Fg7bj017307; Fri, 4 Oct 2002 08:42:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94Fg69e017306; Fri, 4 Oct 2002 08:42:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94Fg3bj017299 for ; Fri, 4 Oct 2002 08:42:03 -0700 (PDT) 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 g94Fg8PG015931 for ; Fri, 4 Oct 2002 08:42:08 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23918 for ; Fri, 4 Oct 2002 09:42:01 -0600 (MDT) 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 g94FfKC00812; Fri, 4 Oct 2002 22:41:21 +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 g94Few714023; Fri, 4 Oct 2002 22:41:00 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Thomas Narten , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <24562.1032861563@munnari.OZ.AU> <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Oct 2002 22:40:58 +0700 Message-ID: <14021.1033746058@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Oct 2002 16:34:02 +0900 From: JINMEI Tatuya Message-ID: | Then the "other documents" should be considered as an implementation | requirement? I'm not sure what you are meaning there? | For example, does RFC 2464 require implementations to | use 64-bit interface identifiers (and prohibit using shorter or longer | identifiers) on ethernet links? No, nothing like that at all. It requires 64 bit IIDs for stateless autoconfiguration to work, which is hardly a surprise (and defines 64 bit IIDs for link local addresses, which is also not exciting) but apart from that, there is no reason for that doc to express any kind of requirement on this, and so it, quite correctly, doesn't. | Also, does RFC 2374 require | implementations to use 64-bit interface identifiers (and prohibit | using others) for aggregatable global unicast addresses? No, it doesn't. That doc kind of assumes the 64 bit IID requirement from the addr arch doc, but nothing in it in any way depends upon that. It is mostly concerned with the upper part of the address (how the prefix is divided up for allocation purposes). Personally I'm not sure the IETF should be getting involved in attempting to specify that in any way (though giving some examples of how it might be done is fine). But in any event, it really has no bearing on the topic being discussed in this thread. | I cannot be clear on those questions just from the specification | documents. I'm not surprised, and I sympathise. Part of the problem is that these docs are attempting to over specify that which does not require specification at all. 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 Oct 4 09:09:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94G91bj017590; Fri, 4 Oct 2002 09:09:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94G91k8017589; Fri, 4 Oct 2002 09:09:01 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g94G8ubj017582 for ; Fri, 4 Oct 2002 09:08:56 -0700 (PDT) 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 g94G92Mq010305 for ; Fri, 4 Oct 2002 09:09:02 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19587 for ; Fri, 4 Oct 2002 10:08:55 -0600 (MDT) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g94G8Yt84359; Sat, 5 Oct 2002 01:08:34 +0900 (JST) Date: Sat, 05 Oct 2002 01:09:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: Thomas Narten , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <14021.1033746058@munnari.OZ.AU> References: <24562.1032861563@munnari.OZ.AU> <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> <14021.1033746058@munnari.OZ.AU> 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 Fri, 04 Oct 2002 22:40:58 +0700, >>>>> Robert Elz said: > | Then the "other documents" should be considered as an implementation > | requirement? > I'm not sure what you are meaning there? I meant to refer to the following part >> It is a >> principle that is to be followed by other documents that specify usage ^^^^^^^^^^^^^^^ >> of the IID. and asked if the usage specified in the "other documents" is an implementation requirement or not. 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 Oct 4 09:34:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94GY3bj017775; Fri, 4 Oct 2002 09:34:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94GY3Xf017774; Fri, 4 Oct 2002 09:34:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94GXxbj017767 for ; Fri, 4 Oct 2002 09:33:59 -0700 (PDT) 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 g94GY4PG027909 for ; Fri, 4 Oct 2002 09:34:05 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02969 for ; Fri, 4 Oct 2002 10:33:59 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.32]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA22366; Fri, 4 Oct 2002 09:33:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 04 Oct 2002 12:32:48 -0400 To: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org From: Margaret Wasserman Subject: Re: Fwd: [ipv6mib] So, where were we? Cc: "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden In-Reply-To: References: <3D92EE70.6658017A@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 All, There have been some recent discussions with the IPv6 MIB design team regarding the direction of our work on IPv6 MIBs that I think would be best discussed on the full IPv6 and MIBs lists. In particular, we have received input from two areas: (1) Folks who would like to see substantial changes to the RFC 2096 update (Forwarding Table MIB), to make it better reflect the structure of forwarding tables on current equipment, be more efficient to use, etc. (2) The authors of a new TCP-related MIB in the transport area who would like to see their changes merged with the new TCP MIB under development in IPv6. This work has been published as: draft-ietf-tsvwg-tcp-mib-extension-XX.txt This whole discussion begs the question of what direction we want to take with our IP version-independent MIBs, and perhaps raises a question of how/where this work should be undertaken. From my perspective, there are two reasonable choices: (1) Update the current IPv4 TCP, UDP, IP and Forwarding Table MIBs to be version-independent (i.e. add IPv6). In this choice, we would make as few changes to those MIBs as possible, in attempt to make the implementation of the new version-independent MIBs as easy as possible for folks who are adding IPv6 to an existing stack. This is the work that we originally started in the IPv6 WG, based on the fact that the main difference in these MIBs would be a transition from IPv4 -> IPv4/IPv6, and we have several IPv6 WG drafts out that reflect this direction. (2) Develop new MIBs for TCP, UDP, IP and Forwarding that reflect the state-of-the-art in each area. This choice involves more work, and may take longer to be adopted, due to larger changes from IPv4 to the IPv4/IPv6 versions. Also, it is pretty clear to me that the IPv6 WG is not the right place to develop a new, substantially different version of the TCP or UDP MIBs. It is also questionable whether a major update to the IP and routing MIBs should be done in IPv6, or in a separate IPv4/IPv6 MIBs group. It is possible that we could do a combined version of these two choices: - The IPv6 WG does the minimal updates to make the current IPv4 MIBs version-independent. - State-of-the-art MIBs are developed in other areas and groups, as appropriate. What do you folks think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 4 09:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94Gf9bj017880; Fri, 4 Oct 2002 09:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94Gf8pm017879; Fri, 4 Oct 2002 09:41:08 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g94Gf5bj017872 for ; Fri, 4 Oct 2002 09:41:05 -0700 (PDT) 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 g94GfBMq018184 for ; Fri, 4 Oct 2002 09:41:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09582 for ; Fri, 4 Oct 2002 09:41:05 -0700 (PDT) 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 g94GeJC02509; Fri, 4 Oct 2002 23:40:20 +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 g94Gdw714370; Fri, 4 Oct 2002 23:39:58 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Thomas Narten , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: <24562.1032861563@munnari.OZ.AU> <200210021433.g92EXvi07972@cichlid.adsl.duke.edu> <14021.1033746058@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Oct 2002 23:39:58 +0700 Message-ID: <14368.1033749598@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 05 Oct 2002 01:09:08 +0900 From: JINMEI Tatuya Message-ID: | and asked if the usage specified in the "other documents" is an | implementation requirement or not. Sorry, I'm still not understanding. An implementation requirement of what? Addressed to whom? Clearly what 2464 says includes requirements upon implementations of 2464. I don't think 2374 really requires much of anyone, it just (attempts to anyway) tell the registries (and sub-registries, etc) how to allocate addresses. I don't think they're directly related to the addr arch doc though? Or not to the current issue anyway. The quote from Thomas in your earlier mail was just his attempt to use 2464 (etc) as demonstrations that 64 bit IIDS had been implemented as specified by addr arch (interpreting addr arch as a specification for RFC writers, rather than anyone else). They wouldn't be relevant, even if this was reasonable, as they don't actually specify what Thomas was hoping or assuming that they do, and so don't further his argument. The whole rest of the community can just ignore that little bit of by-play I think. 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 Oct 4 10:20:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94HKDbj018099; Fri, 4 Oct 2002 10:20:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94HKDPI018098; Fri, 4 Oct 2002 10:20:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94HK9bj018091 for ; Fri, 4 Oct 2002 10:20:09 -0700 (PDT) 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 g94HKEPG010197 for ; Fri, 4 Oct 2002 10:20:15 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16753 for ; Fri, 4 Oct 2002 11:20:09 -0600 (MDT) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g94HJdup021249; Fri, 4 Oct 2002 13:19:39 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 4 Oct 2002 13:19:20 -0400 Message-ID: <3D9DCE3B.80302@nc.rr.com> Date: Fri, 04 Oct 2002 13:22:03 -0400 From: Brian Haberman Organization: Caspian Networks 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: Margaret Wasserman CC: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden Subject: Re: Fwd: [ipv6mib] So, where were we? References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is possible that we could do a combined version of these > two choices: > > - The IPv6 WG does the minimal updates to make the > current IPv4 MIBs version-independent. > - State-of-the-art MIBs are developed in other areas > and groups, as appropriate. > > What do you folks think? I agree with this proposal. The existing work of the IPv6 MIB Design team should be targeted towards making the minimal updates. State-of-the-art MIBs should be undertaken by subject matter experts. 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 Oct 4 10:22:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94HMWbj018116; Fri, 4 Oct 2002 10:22:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94HMWOW018115; Fri, 4 Oct 2002 10:22:32 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g94HMTbj018108 for ; Fri, 4 Oct 2002 10:22:29 -0700 (PDT) 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 g94HMZMq029618 for ; Fri, 4 Oct 2002 10:22:35 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00406 for ; Fri, 4 Oct 2002 11:22:28 -0600 (MDT) 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 g94HHfC03307; Sat, 5 Oct 2002 00:17:42 +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 g94HHE714592; Sat, 5 Oct 2002 00:17:15 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden Subject: Re: Fwd: [ipv6mib] So, where were we? In-Reply-To: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> References: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <3D92EE70.6658017A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Oct 2002 00:17:14 +0700 Message-ID: <14590.1033751834@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Oct 2002 12:32:48 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> | It is possible that we could do a combined version of these | two choices: | | - The IPv6 WG does the minimal updates to make the | current IPv4 MIBs version-independent. | - State-of-the-art MIBs are developed in other areas | and groups, as appropriate. | | What do you folks think? Yes, that. We should make sure that there are IPv6 (or better, address independent) MIBs that at least offer the same functionality as the current IPv4 MIBs. At the same time, the NM people, transport NM people, or whoever, can go on developing their next and greatest MIB, that works better than we currently have, etc. Any such MIB should be address independent now just on general principle. The only thing to be aware of, is that we (IPv6) must avoid getting upset if we do lots of work to update some particular MIB, and then just before we're finished, a new better version emerges from elsewhere (which is intended to deprecate some current v4 only MIB). If that happens, we should just junk whatever we have done, and accept the newer one. If we get finished first, then when a newer one emerges, it can just deprecate our new stuff, as well as the old v4 only stuff. Note that this "do both" is exactly equivalent, to us, to just doing (1) from your two reasonable choices, while at the same time not standing in the way of anyone, from elsewhere, who wants to do (2) (which is obviously the better result - but only if it is actually achieved). 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 Oct 4 11:02:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94I2Mbj018345; Fri, 4 Oct 2002 11:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94I2M6C018344; Fri, 4 Oct 2002 11:02:22 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g94I2Ibj018337 for ; Fri, 4 Oct 2002 11:02:18 -0700 (PDT) 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 g94I2MMq011840 for ; Fri, 4 Oct 2002 11:02:23 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19776 for ; Fri, 4 Oct 2002 12:02:17 -0600 (MDT) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g94I1aup014191; Fri, 4 Oct 2002 14:01:36 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 4 Oct 2002 14:01:17 -0400 Message-ID: <3D9DD811.3000709@nc.rr.com> Date: Fri, 04 Oct 2002 14:04:01 -0400 From: Brian Haberman Organization: Caspian Networks 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: Robert Elz CC: Margaret Wasserman , ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden Subject: Re: Fwd: [ipv6mib] So, where were we? References: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <3D92EE70.6658017A@cisco.com> <14590.1033751834@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > The only thing to be aware of, is that we (IPv6) must avoid getting upset > if we do lots of work to update some particular MIB, and then just before > we're finished, a new better version emerges from elsewhere (which is > intended to deprecate some current v4 only MIB). If that happens, we > should just junk whatever we have done, and accept the newer one. As long as the newer, better version supports IPv6. We do have the responsibility of ensuring v6 support in the new MIBs. As a note, the IPv6 MIB Design Team has been reviewing new MIBs that come out to make sure they are using the INET Address TC where appropriate. 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 Oct 4 11:06:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94I6pbj018443; Fri, 4 Oct 2002 11:06:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94I6pbR018442; Fri, 4 Oct 2002 11:06:51 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g94I6mbj018435 for ; Fri, 4 Oct 2002 11:06:48 -0700 (PDT) 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 g94I6rMq013259 for ; Fri, 4 Oct 2002 11:06:53 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05160 for ; Fri, 4 Oct 2002 12:06:44 -0600 (MDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g94I6VlM046946; Fri, 4 Oct 2002 14:06:31 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g94I7tjd139762; Fri, 4 Oct 2002 12:07:55 -0600 Importance: Normal Sensitivity: Subject: Re: Fwd: [ipv6mib] So, where were we? 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: Fri, 4 Oct 2002 14:06:28 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/04/2002 12:06:30 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are currently working on implementing the July drafts of the version-neutral MIB modules created by the IPv6 MIB design team. We prefer Margaret's first choice: > In this choice, we would make as few changes > to those MIBs as possible, in attempt to make > the implementation of the new version-independent > MIBs as easy as possible for folks who are > adding IPv6 to an existing stack. as we would like to provide basic MIB support for our IPv6 enabled stack as soon as possible. Also, in regards to the ongoing work being done by the IPv6 MIB design team, are there any plans to clean up the July drafts? For example, in the RFC2011 draft, there are table MIB objects that have been deleted but the remaining table objects have not been renumbered. 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 Oct 4 11:18:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94IIobj018605; Fri, 4 Oct 2002 11:18:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94IIoul018604; Fri, 4 Oct 2002 11:18:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94IIlbj018597 for ; Fri, 4 Oct 2002 11:18:47 -0700 (PDT) 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 g94IIpPG027545 for ; Fri, 4 Oct 2002 11:18:51 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28998 for ; Fri, 4 Oct 2002 11:18:46 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.233.32]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA28929; Fri, 4 Oct 2002 11:17:57 -0700 (PDT) Message-Id: <5.1.0.14.2.20021004141756.05754990@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 04 Oct 2002 14:19:37 -0400 To: Kristine Adamson From: Margaret Wasserman Subject: Re: Fwd: [ipv6mib] So, where were we? Cc: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org 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 Hi Kristine, >Also, in regards to the ongoing work being done by the IPv6 MIB design >team, are there any plans to clean up the July drafts? Yes, we have plans to clean up the drafts and get new versions out ASAP. Hopefully we will soon reach last call for UDP & TCP, at least. >For example, in the >RFC2011 draft, there are table MIB objects that have been deleted but the >remaining table objects have not been renumbered. This is sometimes intentional, to avoid incompatibility with implementations of previous versions, but I don't know if that applies in this case. I'll leave it up to the editor of that document to respond. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 4 12:04:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94J4Cbj019058; Fri, 4 Oct 2002 12:04:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94J4BiK019057; Fri, 4 Oct 2002 12:04:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94J48bj019050 for ; Fri, 4 Oct 2002 12:04:09 -0700 (PDT) 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 g94J4EPG010343 for ; Fri, 4 Oct 2002 12:04:14 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05515 for ; Fri, 4 Oct 2002 12:04:08 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 38BEF18E6; Fri, 4 Oct 2002 15:04:07 -0400 (EDT) Date: Fri, 04 Oct 2002 15:04:07 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Cc: mibs@ops.ietf.org, ipv6mib@ibr.cs.tu-bs.de Subject: Re: Fwd: [ipv6mib] So, where were we? In-Reply-To: <14590.1033751834@munnari.OZ.AU> References: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <3D92EE70.6658017A@cisco.com> <14590.1033751834@munnari.OZ.AU> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021004190407.38BEF18E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What KRE said. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 4 12:08:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94J8Kbj019090; Fri, 4 Oct 2002 12:08:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g94J8KtU019089; Fri, 4 Oct 2002 12:08:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g94J8Gbj019082 for ; Fri, 4 Oct 2002 12:08:16 -0700 (PDT) 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 g94J8LPG011390 for ; Fri, 4 Oct 2002 12:08:21 -0700 (PDT) Received: from agile.yagosys.com (host60.riverstonenet.com [64.95.122.60] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA26082 for ; Fri, 4 Oct 2002 13:08:15 -0600 (MDT) Received: (qmail 3017 invoked by uid 10041); 4 Oct 2002 19:08:15 -0000 Date: Fri, 4 Oct 2002 12:08:15 -0700 From: Michael MacFaden To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert \(Bert\)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden Subject: Re: Fwd: [ipv6mib] So, where were we? Message-ID: <20021004190814.GD2627@riverstonenet.com> Mail-Followup-To: Margaret Wasserman , ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> User-Agent: Mutt/1.4i X-Operating-System: GNU/Linux 2.4.18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 04, 2002 at 12:32:48PM -0400, Margaret Wasserman wrote: > (1) Update the current IPv4 TCP, UDP, IP and Forwarding > Table MIBs to be version-independent (i.e. add IPv6). > > In this choice, we would make as few changes > to those MIBs as possible, in attempt to make > the implementation of the new version-independent > MIBs as easy as possible for folks who are > adding IPv6 to an existing stack. > > This is the work that we originally started in > the IPv6 WG, based on the fact that the main > difference in these MIBs would be a transition > from IPv4 -> IPv4/IPv6, and we have several > IPv6 WG drafts out that reflect this direction. > >It is possible that we could do a combined version of these >two choices: > > - The IPv6 WG does the minimal updates to make the > current IPv4 MIBs version-independent. > - State-of-the-art MIBs are developed in other areas > and groups, as appropriate. Doing minimal (1) updates make the most sense to me. Given the history of the IP-FORWARD-MIB: ipRouteTable, ipForwardTable, and the ipCidrRouteTable a minimalist approach might mean we have a higher probability that can get this new work to full standard. Sadly, only the ipRouteTable is at full standard (std17) and we've had mostly cidr networks since '97. I also can't think of a widely deployed device that will provide the new integrated IPv4/IPv6 mib modules that won't continue to ship the existing RFC1213, 1907,2011-13,2096 for backward compatiblity with existing management applications. Regards, Mike MacFaden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 6 02:20:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g969KKbj023840; Sun, 6 Oct 2002 02:20:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g969KKMP023839; Sun, 6 Oct 2002 02:20:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g969KHbj023832 for ; Sun, 6 Oct 2002 02:20:17 -0700 (PDT) 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 g969KNPG003741 for ; Sun, 6 Oct 2002 02:20:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17613 for ; Sun, 6 Oct 2002 03:20:17 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g969KGj12766 for ; Sun, 6 Oct 2002 12:20:16 +0300 Date: Sun, 6 Oct 2002 12:20:16 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Implementation worries about default address selection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Recently I discussed default address selection a bit with implementation folks who were unwilling to put (already implemented) default address selection into the OS. The main reason was that, as currently specified, default address selection seems like something that can't be implemented AS-IS without a big performance degradation. The thing is, it seems like this (IMO relatively complex) iterative comparison algorithm must be run for every outbound packet (one might be able to optimize a bit with connection-oriented protocols). An alternative seems to be to implement some form of (unspecified -- caching is only discussed in the context of dst address selection) optimizations. One example of optimization could be putting the to-be-used source address in the routing table, and refresh it always when rtable or any address of the node changes or changes state (deprecated/preferred, home address etc.), but these might have their own problems. My worry is, is it useful to specify a mechanism for selection default addresses that can't really be used without critical optimizations? ==== A few comments I came across -- the second at least, IMO, requires a clarification. 1. another issue struct me while re-reading: the draft discusses source/destination address selection separately: with S, select D from D_1, D_2, ..., D_n, or with D, select S from S_1, S_2, ..., S_n. If I understood correctly a fairly common case of S_1, S_2, ..., S_n *AND* D_1, D_1, ..., D_n was not elaborated more (a brief mention in section 2?). 2. IMO, I think sections 3.2 and 3.3 may be a bit ambiguous wrt. mapped addresses and scopes. Is it supposed to say that if I have configured '::ffff:10.0.0.1' on an interface (for some reason..), treat it as global (per 3.3), but if I'm communicating via IPv4 (and it was just added to destination address selection as a mapped address ::ffff:10.0.0.1, treat is as site-local (per 3.2))?!? This surely got me confused! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 6 04:38:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g96Bcgbj024077; Sun, 6 Oct 2002 04:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g96BcgEN024076; Sun, 6 Oct 2002 04:38:42 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g96Bcbbj024067 for ; Sun, 6 Oct 2002 04:38:37 -0700 (PDT) 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 g96BchMq021813 for ; Sun, 6 Oct 2002 04:38:43 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24988 for ; Sun, 6 Oct 2002 05:38:36 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:d9d2:f8b9:c87e:1d3e]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g96BcKt94801; Sun, 6 Oct 2002 20:38:21 +0900 (JST) Date: Sun, 06 Oct 2002 20:38:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt In-Reply-To: <200210022029.g92KTnw0002049299@anw.zk3.dec.com> References: <200210022029.g92KTnw0002049299@anw.zk3.dec.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: 84 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 2 Oct 2002 16:29:50 -0400 (EDT), >>>>> Jack McCann said: > So I took a look at 2292bis-07. Hello, thanks for the valuable comments. > Some comments for alignment with the latest POSIX standard: > - I suggest you update the Posix references, using the same > reference as 2553bis, which I show below (note the spec has > now also been approved by ISO): Thomas also asked the update. I'll do that in the next rev. > - protocol family constants (PF_xxx) are not defined in this > latest POSIX standard, replace all PF_xxx with AF_xxx > (e.g. PF_INET -> AF_INET) Yes, PF_xxx was already replaced with AF_xxx in my local copy. The fix will appear in the next rev. > - section 21.1 shows msg_iovlen as type size_t, > the latest POSIX defines msg_iovlen as type int OK. > Some editorial comments: > - section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see > the nice diagram on page 67, an "ancillary data object" includes > the padding at the end) You're right. Thanks for the correction. > - section 8 typo in first paragraph last sentence "Hob-by-Hop" Ditto. > - section 10.5 inet6_opt_next, the statement "Typep points the option > type field" does not seem right, for typep to point to the option > type field, it would have to be passed as 'uint8_t **typep'; I think > you mean it points to a buffer into which the option type is stored, > or using wording similar to lenp, "typep stores the option type" Ditto. I'll change this part to "typep stores the option type". > - section 11.1 you should cite one or more references upon which > this statement is based: > "Also, path MTU discovery for multicast has severe scalability > limitations and should thus be avoided by default." Hmm, I thought this was a kind of common sense these days, but there seems to be no RFC talking about the scalability issue of multicast path MTU discovery. Does anyone in this list know a good reference? > A minor technical comment: > - There is an inconsistency in the inet6_opt_set_val and > inet6_opt_get_val functions. In both functions, the offset > argument is type size_t, but the function return value (also > an offset) is type int. Given the intended usage of these > functions, where the return value of one call can be used as > the offset argument on the next call, the data type of the > offset argument should be type int. > I also want to point out an issue that might be raised if this > API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for > standardization. The functions and macros listed below use a variety > of data types for things that represent a "size", including int, > unsigned int, and size_t. All these items, or at least those of > type size_t, could instead be of type socklen_t. Note that some > of the items identified are for use with msg_controllen and cmsg_len, > which are type socklen_t. OK. I'll check the entire draft and change length types accordingly. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 6 07:37:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g96Ebubj024313; Sun, 6 Oct 2002 07:37:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g96Ebubn024312; Sun, 6 Oct 2002 07:37:56 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g96Ebrbj024305 for ; Sun, 6 Oct 2002 07:37:53 -0700 (PDT) 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 g96EbwMq009839 for ; Sun, 6 Oct 2002 07:37:58 -0700 (PDT) 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 IAA12643 for ; Sun, 6 Oct 2002 08:37:52 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.10]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA10885; Sun, 6 Oct 2002 07:36:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 06 Oct 2002 10:38:32 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com In-Reply-To: <6221.1033626739@munnari.OZ.AU> References: <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >And if I have > > A --------- B --------- C > >And A-B is prefix1::/64 and prefix3::/64, and B-C is prefix2::/64 and >prefix3::/64 (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3) >then subnet local multicast packets arriving at B are ..... ??? You haven't provided the information that router B would use to make that determination. Is router B configured so that the subnet-local zone IDs of its A-B and C-D interfaces are the same or different? If they are the same, then the subnet-local scope encompasses both links, and subnet-local packets will be forwarded. If they are different, then subnet-local packets won't be forwarded. This also applies to your other examples. The unicast addresses uses on those links are immaterial to the decision of whether or not to forward subnet-local packets between these two links. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 7 04:19:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97BJT29026665; Mon, 7 Oct 2002 04:19:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g97BJT3r026664; Mon, 7 Oct 2002 04:19:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97BJP29026657 for ; Mon, 7 Oct 2002 04:19:26 -0700 (PDT) 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 g97BJUMq014887 for ; Mon, 7 Oct 2002 04:19:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04812 for ; Mon, 7 Oct 2002 05:19:25 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13494; Mon, 7 Oct 2002 07:17:19 -0400 (EDT) Message-Id: <200210071117.HAA13494@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-haberman-ipv6-anycast-rr-00.txt Date: Mon, 07 Oct 2002 07:17:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Anycast Binding using Return Routability Author(s) : B. Haberman, E. Nordmark Filename : draft-haberman-ipv6-anycast-rr-00.txt Pages : 5 Date : 2002-10-4 Today, the use of IPv6 anycast is limited. This document proposes a mechanism by which TCP/SCTP and stateful protocols using UDP can securely discover the mapping from an anycast address to a unicast address that can be used until a failure is detected. The mechanism reuses the Mobile IPv6 Return Routability and Binding Update mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberman-ipv6-anycast-rr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haberman-ipv6-anycast-rr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-haberman-ipv6-anycast-rr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-4124459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haberman-ipv6-anycast-rr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haberman-ipv6-anycast-rr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-4124459.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 7 08:59:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97FxX29027774; Mon, 7 Oct 2002 08:59:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g97FxX5l027773; Mon, 7 Oct 2002 08:59:33 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97FxU29027766 for ; Mon, 7 Oct 2002 08:59:30 -0700 (PDT) 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 g97FxZMq027737 for ; Mon, 7 Oct 2002 08:59:35 -0700 (PDT) Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21748 for ; Mon, 7 Oct 2002 08:59:29 -0700 (PDT) Received: from Rich3800@aol.com by imo-d02.mx.aol.com (mail_out_v34.13.) id 1.d4.1e5ab407 (16112) for ; Mon, 7 Oct 2002 11:59:22 -0400 (EDT) Received: from aol.com (ool-182c7f51.dyn.optonline.net [24.44.127.81]) by air-id12.mx.aol.com (v89.10) with ESMTP id MAILINID124-1007115922; Mon, 07 Oct 2002 11:59:22 -0400 Message-ID: <3DA1AF7F.4050005@aol.com> Date: Mon, 07 Oct 2002 11:59:59 -0400 From: Rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 options for home network 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 I would like to know what my IPv6 options would be for my network configuration. My network is made up of 2 PCs : my PC is running SuSE linux professional 7.3 (but Red Hat 7.3 can also be installed), it is a Pentium III desktop with 320 Mb RAM and a 40 Gb hard drive, the othe PC is a Dell laptop running Windows 98 SE. The network configuration is: Internet service comes in from Cablevision in Connecticut, comes in by DHCP protocol to a Motorola SB4200 cable modem, which is connected to a Speedstream 2602 NAT server/firewall, which is split into 2 connections, one wired for the desktop and the other to a US Robotics wireless router connecting wirelessly to the laptop. I want to run a publicly accessible IPv6/IPv4 Zope web server and I read that it is very hard to do if behind 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 Mon Oct 7 09:01:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97G1r29027820; Mon, 7 Oct 2002 09:01:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g97G1rhT027819; Mon, 7 Oct 2002 09:01:53 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97G1o29027812 for ; Mon, 7 Oct 2002 09:01:50 -0700 (PDT) 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 g97G1sMq028475 for ; Mon, 7 Oct 2002 09:01:54 -0700 (PDT) Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08083 for ; Mon, 7 Oct 2002 10:01:48 -0600 (MDT) Received: from Rich3800@aol.com by imo-d06.mx.aol.com (mail_out_v34.13.) id 1.18e.f6badd8 (16100) for ; Mon, 7 Oct 2002 12:01:44 -0400 (EDT) Received: from aol.com (ool-182c7f51.dyn.optonline.net [24.44.127.81]) by air-id11.mx.aol.com (v89.10) with ESMTP id MAILINID114-1007120144; Mon, 07 Oct 2002 12:01:44 -0400 Message-ID: <3DA1B00D.6050901@aol.com> Date: Mon, 07 Oct 2002 12:02:21 -0400 From: Rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Online IPv6 classes 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 Anybody giving online IPv6 classes? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 7 09:26:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97GQM29028080; Mon, 7 Oct 2002 09:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g97GQMUn028079; Mon, 7 Oct 2002 09:26:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g97GQJ29028072 for ; Mon, 7 Oct 2002 09:26:19 -0700 (PDT) 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 g97GQNPG022223 for ; Mon, 7 Oct 2002 09:26:23 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29029 for ; Mon, 7 Oct 2002 10:26:17 -0600 (MDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g97GQbF26976; Mon, 7 Oct 2002 12:26:37 -0400 Date: Mon, 7 Oct 2002 12:26:36 -0400 (EDT) From: Joe Baptista To: Rich3800 cc: Subject: INTERVIEW of home user RICH on IPv6 infrastructure In-Reply-To: <3DA1AF7F.4050005@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Rich: On Mon, 7 Oct 2002, Rich3800 wrote: > I would like to know what my IPv6 options would be for my network > configuration. My network is made up of 2 PCs : my PC is running SuSE > linux professional 7.3 (but Red Hat 7.3 can also be installed), it is > a Pentium III desktop with 320 Mb RAM and a 40 Gb hard drive, the othe > PC is a Dell laptop running Windows 98 SE. The network configuration > is: Internet service comes in from Cablevision in Connecticut, comes > in by DHCP protocol to a Motorola SB4200 cable modem, which is > connected to a Speedstream 2602 NAT server/firewall, which is split > into 2 connections, one wired for the desktop and the other to a US > Robotics wireless router connecting wirelessly to the laptop. I want > to run a publicly accessible IPv6/IPv4 Zope web server and I read that > it is very hard to do if behind NAT. My name is Joe Baptista and I'm doing an article for circleID on IPv6, http://www.circleid.com/ and would like to interview you from the home users perspective. I've attached some notes. And you can find my two prior articles online at the following locations: http://www.circleid.com/articles/2533.asp and http://www.circleid.com/articles/2539.asp I would like to get your view on some notes i've been making. Please feel free to repond in brief or detail to my notes. As a potential home user for the technology I'd like your opinions. Pro or con - good or bad. That is if you agree to be interviewed ;) Here's what I think [-) IPv6 registration fees remind me of an MLM (Multi-Level Marketing) project established by the registries to be money generators. It's my position that if IPv6 has to take off a number of factors will have to be addressed. And one of the pressing factors is fees. I assume your Organization has the standard /32 initial IPv6 allocation (or more) and that the annual fee of $2,500 (US) applies. I know a /32 can give you a lot of /48 so the cost is peanuts to the end user maybe ? but still my concern is that IPv6 can be used by many organizations and individuals to build permanent infrastructure and that this fee based system simply can't be rationalized. The bulk of infrastructure routing is performed by various upstreams not ARIN or IANA. I think this is highway robbery by IANA and friends. At best the registries in my opinion provide reverse resolution and that does not cost $2,500 per /48. At best $6.00 a year will provide enough for reverse resolution. Because of routing issues they can't even get the allocations back so i'm sure many would pay fees and never bother paying again. David Conrad at ARIN admitted as much recently in conferences. The registries I see now require a contractual obligation from the IPv4 and IPv6 operators as a means of securing their right to have the allocation returned. It's my position that infrastructure, be it IPv4 or IPv6, is a valuable means of assigning fixed infrastructure to internet assets (servers, etc.). Any technician who knows the horror of renumbering can attest to that. Unfortunately these fees will make it very difficult for many non profits or persons to aquire infrastructure. Another concern I have involves the complete lack of advertising and marketing efforts behind IPv6. I am speaking specifically with respect to major corporations. Why has the public not been notifed of IPv6 as an option in new releases like Microsoft Windows XP. I think Microsoft and any other corporation with a stake in IPv6 should be marketing it to death. Finally the user has the power to become their own ISP and broker connections into the IPv6 cloud through various providers across the entire network. A good marketing campaign will generate user interest in infrastructure andforce isp's to begin offering IPv6 services to their users. I think tunnel brokers are doing an excellent job to fill in the cracks - but even the ipv6forum has no quick list of providers available and in my opinion it should and the providers should be listed on it. Has anything been done in the marketing arena by the major players? Maybe i'm being too bitchy with my concerns and these things will iron themselves out. Im sure you can provide a better opinion then I can. I'm also concerned about security. IPv6 I think provides adequate privacy to the end user especially if the end users system supports RFC 3041 and the transactions are performed through tunnel brokers. Security however I think is still in the early stages. I've seen a lot of security protocols which were deamed insecure over time and the basic problem seems to be the fact that the original internet was designed around trust factors more then security issues. I'm also concerned that tunnel brokers may not have considered spamers using IPv6 tunnels as a means of masking their origins through tunnel brokers. Is this a problem you can see affecting the business of a tunnel broker? My concerns are the overhead of technical or abuse support. This sort of problem has happened to Freenet6 in montreal. And I'm curious if it's been a problem to you (IPv6 tunnel brokers). I've also spoken with a security expert who agrees with me that IPv6 could be abused for launching DDOS attacks. He pointed out many Unix and Windows boxes are heavily firewalled in IPv4, but not in IPv6. If you happen to be on their local link (hello wireless) one can circumvent the IPv4 access restrictions for services that are v6-enabled. He speculates it may be the case that owners often don't even know the box is doing v6. These are just some of my concerns. Please feel free to address them in details or ask question if you want me to explain my conerns in detail. Regards Joe Baptista # EOF Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 7 22:02:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9852C29001818; Mon, 7 Oct 2002 22:02:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9852Crq001817; Mon, 7 Oct 2002 22:02:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9852829001810 for ; Mon, 7 Oct 2002 22:02:08 -0700 (PDT) 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 g9852CPG003806 for ; Mon, 7 Oct 2002 22:02:12 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02861 for ; Mon, 7 Oct 2002 23:02:07 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 015CF4B23; Tue, 8 Oct 2002 14:02:03 +0900 (JST) To: Rich3800 Cc: ipng@sunroof.eng.sun.com In-reply-to: Rich3800's message of Mon, 07 Oct 2002 12:02:21 -0400. <3DA1B00D.6050901@aol.com> 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: Online IPv6 classes From: itojun@iijlab.net Date: Tue, 08 Oct 2002 14:02:03 +0900 Message-Id: <20021008050204.015CF4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Anybody giving online IPv6 classes? http://www.soi.wide.ad.jp/ has some IPv6 tutorials online. 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 Oct 7 22:02:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9852J29001828; Mon, 7 Oct 2002 22:02:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9852JgS001827; Mon, 7 Oct 2002 22:02:19 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9852F29001820 for ; Mon, 7 Oct 2002 22:02:15 -0700 (PDT) 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 g9852JMq025775 for ; Mon, 7 Oct 2002 22:02:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04904 for ; Mon, 7 Oct 2002 22:02:13 -0700 (PDT) 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 g9851XC29605; Tue, 8 Oct 2002 12:01:34 +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 g976Lqs14082; Mon, 7 Oct 2002 13:21:52 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 2002 13:21:52 +0700 Message-ID: <14080.1033971712@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 06 Oct 2002 10:38:32 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> | You haven't provided the information that router B would use | to make that determination. Brian Haberman provided an entirely good enough answer (which also was that there wasn't enough information, but with different missing info). | Is router B configured so that the subnet-local zone IDs of its | A-B and C-D interfaces are the same or different? What subnet local zone id ? I wasn't aware that such a thing existed? If it did, it would have to be assigned, which would make subnet-local multicast jump out of the category of "no special config required" that is (I think rightly) claimed for it, wouldn't it? | The unicast addresses uses on those links are immaterial to the | decision of whether or not to forward subnet-local packets between | these two links. Hmm ... that is exactly the opposite of what Brian said, and is also contrary to what (little) I know about multicast forwarding. Generally that's done based upon the (unicast) source address of the packet (along with the destination address, naturally). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 7 22:13:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g985DA29002011; Mon, 7 Oct 2002 22:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g985DAbc002010; Mon, 7 Oct 2002 22:13:10 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g985D629002003 for ; Mon, 7 Oct 2002 22:13:07 -0700 (PDT) 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 g985DBMq027152 for ; Mon, 7 Oct 2002 22:13:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21503 for ; Mon, 7 Oct 2002 23:13:05 -0600 (MDT) 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 g9852NC00488; Tue, 8 Oct 2002 12:02:26 +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 g95EEUs03088; Sat, 5 Oct 2002 21:14:30 +0700 (ICT) From: Robert Elz To: Brian Haberman cc: Margaret Wasserman , ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, "Wijnen, Bert (Bert)" , ipv6mib@ibr.cs.tu-bs.de, Scott Bradner , Allison Mankin , Matt Mathis , Thomas Narten , Steve Deering , Bob Hinden Subject: Re: Fwd: [ipv6mib] So, where were we? In-Reply-To: <3D9DD811.3000709@nc.rr.com> References: <3D9DD811.3000709@nc.rr.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <3D92EE70.6658017A@cisco.com> <14590.1033751834@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Oct 2002 21:14:30 +0700 Message-ID: <3086.1033827270@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Oct 2002 14:04:01 -0400 From: Brian Haberman Message-ID: <3D9DD811.3000709@nc.rr.com> | As long as the newer, better version supports IPv6. Of course. My expectation would be that any new mib, or for that matter, any new anything (as much as it is relevant) now must support IPv6 to be accepted. 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 Oct 8 04:44:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Bia29003388; Tue, 8 Oct 2002 04:44:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98BiaIF003387; Tue, 8 Oct 2002 04:44:36 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98BiX29003379 for ; Tue, 8 Oct 2002 04:44:33 -0700 (PDT) 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 g98BibMq019115 for ; Tue, 8 Oct 2002 04:44:37 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09188 for ; Tue, 8 Oct 2002 04:44:31 -0700 (PDT) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g98Bhuup029349; Tue, 8 Oct 2002 07:43:56 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 8 Oct 2002 07:43:43 -0400 Message-ID: <3DA2C59B.6090104@nc.rr.com> Date: Tue, 08 Oct 2002 07:46:35 -0400 From: Brian Haberman Organization: Caspian Networks 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: Robert Elz CC: Margaret Wasserman , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <14080.1033971712@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Sun, 06 Oct 2002 10:38:32 -0400 > From: Margaret Wasserman > Message-ID: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> > > | You haven't provided the information that router B would use > | to make that determination. > > Brian Haberman provided an entirely good enough answer (which also was > that there wasn't enough information, but with different missing info). > > | Is router B configured so that the subnet-local zone IDs of its > | A-B and C-D interfaces are the same or different? > > What subnet local zone id ? A border router between subnet local zones will have subnet zone ids assigned to each interface (see sections 5 & 6 of draft-ietf-ipngwg-scoping-arch-04.txt). > I wasn't aware that such a thing existed? > If it did, it would have to be assigned, which would make subnet-local > multicast jump out of the category of "no special config required" > that is (I think rightly) claimed for it, wouldn't it? Not necessarily. This was covered in a previous thread, but it is possible that a router could detect that a common prefix has been assigned to multiple interfaces and set the subnet-local zone id appropriately. > > | The unicast addresses uses on those links are immaterial to the > | decision of whether or not to forward subnet-local packets between > | these two links. > > Hmm ... that is exactly the opposite of what Brian said, and is also > contrary to what (little) I know about multicast forwarding. Generally > that's done based upon the (unicast) source address of the packet (along > with the destination address, naturally). Section 9 of draft-ietf-ipngwg-scoping-arch-04.txt explicitly states that when forwarding packets with a less than globally scoped destination address, the scope of the source address and the incoming interface zone id are taken into account. 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 Oct 8 04:52:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Bqe29003443; Tue, 8 Oct 2002 04:52:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98BqeeI003442; Tue, 8 Oct 2002 04:52:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Bqb29003435 for ; Tue, 8 Oct 2002 04:52:37 -0700 (PDT) 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 g98BqfPG023429 for ; Tue, 8 Oct 2002 04:52:41 -0700 (PDT) Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24878 for ; Tue, 8 Oct 2002 05:52:35 -0600 (MDT) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id E5A954B1 for ; Tue, 8 Oct 2002 13:58:34 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 7AB64B4FA; Tue, 8 Oct 2002 07:01:50 -0500 (CDT) Message-ID: <3DA2C776.8B190A2@6wind.com> Date: Tue, 08 Oct 2002 13:54:30 +0200 From: ARt X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: IPv6 Subject: About subnet-router anycast address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In RFC2373, a subnet-router anycast address is defined, from the prefixes available on a link, with host ID part set to 0. Should it be done also for the link-local prefix ? i.e. is it mandatory for a router to answer to the fe80:: anycast address ? If yes, would it make sense for a host on a link to configure its default route with fe80:: as gateway, without managing a default gateway list, and instead relying on NDP/NUD to switch from a dead gateway ? Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 04:58:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Bwr29003505; Tue, 8 Oct 2002 04:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98BwrdU003504; Tue, 8 Oct 2002 04:58:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Bwo29003497 for ; Tue, 8 Oct 2002 04:58:50 -0700 (PDT) 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 g98BwsPG024056 for ; Tue, 8 Oct 2002 04:58:54 -0700 (PDT) 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 FAA15867 for ; Tue, 8 Oct 2002 05:58:48 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA24595; Tue, 8 Oct 2002 04:57:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Oct 2002 07:58:11 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com In-Reply-To: <14080.1033971712@munnari.OZ.AU> References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:21 AM 10/7/02, Robert Elz wrote: > Date: Sun, 06 Oct 2002 10:38:32 -0400 > From: Margaret Wasserman > Message-ID: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> > > | You haven't provided the information that router B would use > | to make that determination. > >Brian Haberman provided an entirely good enough answer (which also was >that there wasn't enough information, but with different missing info). Well, I'll defer to Brian. His source address explanation is cleaner and more intuitive than my zone ID explanation. It also has the benefit that it matches what is in the addressing architecture document. I'm not sure, though, that Brian's explanation is consistent with the following line in the scoped address architecture: "Each interface belongs to exactly one zone of each possible scope." Based on Brian's explanation, it would seem like the interfaces of router B are actually each in two subnet-local zones, and router B is using the source address of received packets to choose between them. Brian? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 8 05:13:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98CDU29003624; Tue, 8 Oct 2002 05:13:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98CDTYS003623; Tue, 8 Oct 2002 05:13:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98CDQ29003616 for ; Tue, 8 Oct 2002 05:13:26 -0700 (PDT) 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 g98CDVMq022948 for ; Tue, 8 Oct 2002 05:13:31 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23025 for ; Tue, 8 Oct 2002 06:13:25 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g98CDLup023794; Tue, 8 Oct 2002 08:13:21 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 8 Oct 2002 08:13:07 -0400 Message-ID: <3DA2CC80.6050901@nc.rr.com> Date: Tue, 08 Oct 2002 08:16:00 -0400 From: Brian Haberman Organization: Caspian Networks 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: Margaret Wasserman CC: Robert Elz , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > I'm not sure, though, that Brian's explanation is consistent with the > following line in the scoped address architecture: > > "Each interface belongs to exactly one zone of each possible scope." > > Based on Brian's explanation, it would seem like the interfaces of > router B are actually each in two subnet-local zones, and router B > is using the source address of received packets to choose between > them. Brian? Good catch Margaret. I should have noticed that the example given actually violates the scoped addressing architecture doc. The forwarding logic is still correct, but you can only have, at most, one zone id per scope per interface. Otherwise you would have overlapping scope zones. 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 Oct 8 07:52:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98EqQ29004152; Tue, 8 Oct 2002 07:52:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98EqQYr004151; Tue, 8 Oct 2002 07:52:26 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98EqN29004144 for ; Tue, 8 Oct 2002 07:52:23 -0700 (PDT) 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 g98EqRMq019481 for ; Tue, 8 Oct 2002 07:52:27 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20864 for ; Tue, 8 Oct 2002 08:52:20 -0600 (MDT) 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 g98EqJaI054600 for ; Tue, 8 Oct 2002 10:52:19 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98EqHZE137270 for ; Tue, 8 Oct 2002 08:52:18 -0600 Importance: Normal Sensitivity: Subject: New version-neutral MIB drafts - deprecated MIB objects used in other MIB modules To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Tue, 8 Oct 2002 10:52:16 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/08/2002 08:52:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, We are trying to implement the new version-neutral MIB data provided by the IPv6 MIB Design team. We have found that another MIB module we support, the IPOA-MIB from RFC2320, uses some of the newly deprecated MIB objects in the new RFC2011 draft. For example, table entry ipoaArpClientEntry from the IPOA-MIB defines the ipAdEntAddr MIB object (from the ipAddrTable in the old RFC2011) as the index of the ipoaArpClientTable. Will this cause problems with MIB browsers or other programs that parse the MIB module because ipoaArpClientEntry has a status of "current" but ipAdEntAddr has a status of "deprecated"? 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 Oct 8 08:01:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98F1x29004211; Tue, 8 Oct 2002 08:01:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98F1wbw004210; Tue, 8 Oct 2002 08:01:58 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98F1t29004203 for ; Tue, 8 Oct 2002 08:01:55 -0700 (PDT) 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 g98F20Mq021126 for ; Tue, 8 Oct 2002 08:02:00 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28594 for ; Tue, 8 Oct 2002 08:01:54 -0700 (PDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98F1r6m027862 for ; Tue, 8 Oct 2002 11:01:53 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98F1x7l155886 for ; Tue, 8 Oct 2002 09:02:00 -0600 Importance: Normal Sensitivity: Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt - new ioctls? To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Tue, 8 Oct 2002 11:00:27 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/08/2002 09:00:28 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 25 Sep 2002 Pekka Savola wrote: >>This is probably a dumb question, but is there must be a reason why these >>API's don't talk at all about ioctl's etc? For example, I see no standard >>way of obtaining (all or some) of one's IPv6 addresses, or whatever else >>was useful with SIOC*. We also have wondered if there are going to be either IPv6-specific or version-neutral replacements for the SIOCGIF* ioctls that use an ifreq structure? 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 Oct 8 09:23:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GNk29004598; Tue, 8 Oct 2002 09:23:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98GNkSY004597; Tue, 8 Oct 2002 09:23:46 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GNg29004590 for ; Tue, 8 Oct 2002 09:23:43 -0700 (PDT) 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 g98GNlMq008822 for ; Tue, 8 Oct 2002 09:23:47 -0700 (PDT) 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 KAA21471 for ; Tue, 8 Oct 2002 10:23:28 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.37]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA23505; Tue, 8 Oct 2002 09:21:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Oct 2002 12:19:44 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Robert Elz , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com In-Reply-To: <3DA2CC80.6050901@nc.rr.com> References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Good catch Margaret. I should have noticed that the example given >actually violates the scoped addressing architecture doc. The >forwarding logic is still correct, but you can only have, at most, >one zone id per scope per interface. Otherwise you would have >overlapping scope zones. Are you sure? I originally began an answer to Robert's third example with something like "this is an invalid configuration". However, I realized that I was mistaken. Assuming that router B has support for multi-link subnets, Robert's example is a valid configuration showing a subnet-local zone that encompasses two links. There is no requirement that all hosts within a given zone need to configure addresses from (all of) the unicast prefix(es) within that zone, or that all routers need to advertise the same unicast prefixes on all interfaces within a given zone. Is there? The real question is this: By default, if a router is configured to advertise the same prefix on two interfaces, should the router assume that the two interfaces are in the same subnet-local zone? Should the router assume that the two interfaces are on the same link (i.e. in the same link-local zone)? These are questions that need to be answered in the scoped address architecture. I think it would be a reasonable default for a router that is configured with the same prefix on two interfaces to assume that those interfaces are on the same link (same link-local zone), and in the same subnet-local zone. In other words, I think that routers should default to the single-link subnet case, unless mutli-link subnetting has been explicitly configured. What do you think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 8 09:30:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GUp29004648; Tue, 8 Oct 2002 09:30:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98GUoSu004647; Tue, 8 Oct 2002 09:30:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GUl29004640 for ; Tue, 8 Oct 2002 09:30:47 -0700 (PDT) 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 g98GUqMq010989 for ; Tue, 8 Oct 2002 09:30:52 -0700 (PDT) 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 KAA20140 for ; Tue, 8 Oct 2002 10:30:46 -0600 (MDT) Message-ID: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> From: "James Kempf" To: Subject: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 8 Oct 2002 09:29:12 -0700 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 Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS reply timing: http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt I didn't see an announcement from the drafts editor in this group. In summary, the draft amends RFC 2461 to allow at most one router on a link to reply immediately to an RS instead of waiting a random amount of time between 0 and MAX_RA_DELAY_TIME. The router is allowed to reply to at most MAX_FAST_RAS since the last unsolicited multicast is sent. If this number is exceeded, the router rolls over to scheduling a multicast RA as soon as possible. This is intended to avoid DoS attacks on the router. We believe this amendment will be necessary for achieving good handover performance with standard Mobile IPv6 movement detection. If the mobile node is capable of detecting when the link changes, it can immediately send an RS rather than wait for a multicast RA. This can significantly decrease the amount of time required for movement detection. In addition to theoretical considerations, we have some amount of implementation experience with the existing movement detection algorithm to suggest that the RS reply protocol in RFC 2461 could have moderate to severe performance limiting effects on standard MIPv6 handover. We would like to have review and discussion of this draft prior to the WG meeting in Atlanta, and finish up the discussion there, with a goal of making this a WG document. The Mobile IP working group will be finishing up the MIPv6 draft soon, and we would like to be able to publish this draft in about the same time frame, so implementors have some guidance. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 8 09:47:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GlW29004819; Tue, 8 Oct 2002 09:47:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98GlVau004816; Tue, 8 Oct 2002 09:47:31 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98GlS29004805 for ; Tue, 8 Oct 2002 09:47:28 -0700 (PDT) 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 g98GlWMq015460 for ; Tue, 8 Oct 2002 09:47:32 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16878 for ; Tue, 8 Oct 2002 09:47:27 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D8E0A18E6 for ; Tue, 8 Oct 2002 12:47:24 -0400 (EDT) Date: Tue, 08 Oct 2002 12:47:24 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> <3DA2CC80.6050901@nc.rr.com> <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021008164724.D8E0A18E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 08 Oct 2002 12:19:44 -0400, Margaret Wasserman wrote: > > In other words, I think that routers should default to the > single-link subnet case, unless mutli-link subnetting has been > explicitly configured. I 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 Tue Oct 8 10:28:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98HSH29005153; Tue, 8 Oct 2002 10:28:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98HSHlP005152; Tue, 8 Oct 2002 10:28:17 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98HSE29005145 for ; Tue, 8 Oct 2002 10:28:14 -0700 (PDT) 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 g98HSIMq026249 for ; Tue, 8 Oct 2002 10:28:18 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03762 for ; Tue, 8 Oct 2002 11:28:12 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 276AB58EA; Tue, 8 Oct 2002 13:28:12 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 561231179; Tue, 8 Oct 2002 12:28:11 -0500 (CDT) Message-ID: <3DA315AA.1000408@hp.com> Date: Tue, 08 Oct 2002 13:28:10 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James I think that the draft is missing a trigger mechanism for a fast RA response. What I mean is, that if any node not requiring a fast RA joins the link, it will use up a fast RA that will potentially cause delays for a node that would really like a fast answer. You could take one of the reserved bits from the RS (there are 32 of them) and turn it in to the fast RA flag. The node that would really like a fast answer must set the flag. The flag will be ignored by routers that do not support fast RAs (according to 2461). This doesn't get rid of the malicious node consuming all of the fast RAs, but it provides the ablility to send the RAs sparingly. -vlad James Kempf wrote: > Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS > reply timing: > > http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt > > I didn't see an announcement from the drafts editor in this group. > > In summary, the draft amends RFC 2461 to allow at most one router on a link to > reply immediately to an RS instead of waiting a random amount of time between 0 > and MAX_RA_DELAY_TIME. The router is allowed to reply to at most MAX_FAST_RAS > since the last unsolicited multicast is sent. If this number is exceeded, the > router rolls over to scheduling a multicast RA as soon as possible. This is > intended to avoid DoS attacks on the router. > > We believe this amendment will be necessary for achieving good handover > performance with standard Mobile IPv6 movement detection. If the mobile node is > capable of detecting when the link changes, it can immediately send an RS rather > than wait for a multicast RA. This can significantly decrease the amount of time > required for movement detection. In addition to theoretical considerations, we > have some amount of implementation experience with the existing movement > detection algorithm to suggest that the RS reply protocol in RFC 2461 could have > moderate to severe performance limiting effects on standard MIPv6 handover. > > We would like to have review and discussion of this draft prior to the WG > meeting in Atlanta, and finish up the discussion there, with a goal of making > this a WG document. The Mobile IP working group will be finishing up the MIPv6 > draft soon, and we would like to be able to publish this draft in about the same > time frame, so implementors have some guidance. > > jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 10:55:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Ht329005266; Tue, 8 Oct 2002 10:55:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98Ht3Iu005265; Tue, 8 Oct 2002 10:55:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Hsx29005258 for ; Tue, 8 Oct 2002 10:55:00 -0700 (PDT) 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 g98Ht4PG002071 for ; Tue, 8 Oct 2002 10:55:04 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07720 for ; Tue, 8 Oct 2002 10:54:58 -0700 (PDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g98HrtiZ006198; Tue, 8 Oct 2002 13:53:55 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 8 Oct 2002 13:54:05 -0400 Message-ID: <3DA31C6A.2030107@nc.rr.com> Date: Tue, 08 Oct 2002 13:56:58 -0400 From: Brian Haberman Organization: Caspian Networks 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: Margaret Wasserman CC: Robert Elz , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >> >> Good catch Margaret. I should have noticed that the example given >> actually violates the scoped addressing architecture doc. The >> forwarding logic is still correct, but you can only have, at most, >> one zone id per scope per interface. Otherwise you would have >> overlapping scope zones. > > > Are you sure? > > I originally began an answer to Robert's third example with something > like "this is an invalid configuration". However, I realized that I > was mistaken. If the rule stands that an interface can have no more than one zone id per scope, then it is invalid if we expect a subnet-local zone id to automatically appear when a prefix is configured on an interface. So, going back to Robert's example: A --------- B --------- C - A-B is prefix1::/64 and prefix3::/64 - B-C is prefix2::/64 and prefix3::/64 - (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3) As long as B has one subnet-local scope zone id per interface, the forwarding logic I described will work. You could make it work with multiple zone ids on an interface, but the logic would require a complicated RPF check on the source address in order to determine which zone id to use in the forwarding decision. I don't think I want to go there. > > Assuming that router B has support for multi-link subnets, Robert's > example is a valid configuration showing a subnet-local zone > that encompasses two links. It is valid from the base architecture. It is valid from the scoping architecture if there is no more than one subnet-local scope zone id. > > There is no requirement that all hosts within a given zone need > to configure addresses from (all of) the unicast prefix(es) > within that zone, or that all routers need to advertise the same > unicast prefixes on all interfaces within a given zone. Is there? Not that I know of. > > The real question is this: > > By default, if a router is configured to advertise the same prefix > on two interfaces, should the router assume that the two interfaces > are in the same subnet-local zone? Should the router assume that > the two interfaces are on the same link (i.e. in the same link-local > zone)? The more I think about it, the more I realize that "automagically" creating the subnet-local scope zone id isn't going to work. Especially with multiple prefixes per interface. > > These are questions that need to be answered in the scoped address > architecture. I think the addressing architecture needs to address the comment on automatically creating the subnet-local zone id. > > I think it would be a reasonable default for a router that is > configured with the same prefix on two interfaces to assume that > those interfaces are on the same link (same link-local zone), and > in the same subnet-local zone. But if they aren't on the same link, forwarding could break. > > In other words, I think that routers should default to the > single-link subnet case, unless mutli-link subnetting has been > explicitly configured. This is slightly different than assuming that the interfaces are on the same link. If the router treats them as unique prefixes, then forwarding and routing should work. 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 Oct 8 11:06:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98I6P29005427; Tue, 8 Oct 2002 11:06:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98I6PYP005426; Tue, 8 Oct 2002 11:06:25 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98I6M29005416 for ; Tue, 8 Oct 2002 11:06:22 -0700 (PDT) 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 g98I6QMq008020 for ; Tue, 8 Oct 2002 11:06:26 -0700 (PDT) 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 MAA04807 for ; Tue, 8 Oct 2002 12:06:20 -0600 (MDT) Message-ID: <012801c26ef5$2ba32430$056015ac@T23KEMPF> From: "James Kempf" To: "Vladislav Yasevich" Cc: References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <3DA315AA.1000408@hp.com> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 8 Oct 2002 11:04:37 -0700 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 Vlad, Good point. This would work for the normal circumstance, though it would not deter an attacker, as you point out. jak ----- Original Message ----- From: "Vladislav Yasevich" To: "James Kempf" Cc: Sent: Tuesday, October 08, 2002 10:28 AM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > James > > I think that the draft is missing a trigger mechanism for a fast RA > response. What I mean is, that if any node not requiring a fast RA > joins the link, it will use up a fast RA that will potentially cause > delays for a node that would really like a fast answer. > > You could take one of the reserved bits from the RS (there are 32 of them) > and turn it in to the fast RA flag. The node that would really like > a fast answer must set the flag. The flag will be ignored by routers > that do not support fast RAs (according to 2461). > > This doesn't get rid of the malicious node consuming all of the fast > RAs, but it provides the ablility to send the RAs sparingly. > > -vlad > > James Kempf wrote: > > Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS > > reply timing: > > > > http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt > > > > I didn't see an announcement from the drafts editor in this group. > > > > In summary, the draft amends RFC 2461 to allow at most one router on a link to > > reply immediately to an RS instead of waiting a random amount of time between 0 > > and MAX_RA_DELAY_TIME. The router is allowed to reply to at most MAX_FAST_RAS > > since the last unsolicited multicast is sent. If this number is exceeded, the > > router rolls over to scheduling a multicast RA as soon as possible. This is > > intended to avoid DoS attacks on the router. > > > > We believe this amendment will be necessary for achieving good handover > > performance with standard Mobile IPv6 movement detection. If the mobile node is > > capable of detecting when the link changes, it can immediately send an RS rather > > than wait for a multicast RA. This can significantly decrease the amount of time > > required for movement detection. In addition to theoretical considerations, we > > have some amount of implementation experience with the existing movement > > detection algorithm to suggest that the RS reply protocol in RFC 2461 could have > > moderate to severe performance limiting effects on standard MIPv6 handover. > > > > We would like to have review and discussion of this draft prior to the WG > > meeting in Atlanta, and finish up the discussion there, with a goal of making > > this a WG document. The Mobile IP working group will be finishing up the MIPv6 > > draft soon, and we would like to be able to publish this draft in about the same > > time frame, so implementors have some guidance. > > > > jak > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 14:48:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Lmm29006331; Tue, 8 Oct 2002 14:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98LmloB006330; Tue, 8 Oct 2002 14:48:47 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Lmh29006323 for ; Tue, 8 Oct 2002 14:48:43 -0700 (PDT) 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 g98LmlMq007504 for ; Tue, 8 Oct 2002 14:48:47 -0700 (PDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22021 for ; Tue, 8 Oct 2002 15:48:41 -0600 (MDT) 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.3/8.12.3/Debian -4) with ESMTP id g98Lm5Rd001094 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 8 Oct 2002 23:48:05 +0200 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 g98Lm4Ht029970 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 8 Oct 2002 23:48:04 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id g98Lm1wG029967; Tue, 8 Oct 2002 23:48:01 +0200 Date: Tue, 8 Oct 2002 23:48:01 +0200 Message-Id: <200210082148.g98Lm1wG029967@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mrm@riverstonenet.com CC: mrw@windriver.com, ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, bwijnen@lucent.com, ipv6mib@ibr.cs.tu-bs.de, sob@harvard.edu, mankin@isi.edu, mathis@psc.edu, narten@us.ibm.com, deering@cisco.com, hinden@iprg.nokia.com In-reply-to: <20021004190814.GD2627@riverstonenet.com> (message from Michael MacFaden on Fri, 4 Oct 2002 12:08:15 -0700) Subject: Re: Fwd: [ipv6mib] So, where were we? References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <20021004190814.GD2627@riverstonenet.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> Michael MacFaden writes: Michael> Given the history of the IP-FORWARD-MIB: ipRouteTable, Michael> ipForwardTable, and the ipCidrRouteTable a minimalist Michael> approach might mean we have a higher probability that can get Michael> this new work to full standard. The problem with the IP-FORWARD-MIB is that many systems use forwarding bases which are much richer than what the indexing allows to report. On such systems, implementing the ipCidrRouteTable (and the ipRouteTable) means to report only a subset of the real forwarding information. Hence, management applications which try to interpret these MIB tables are kind of fooled. This is of course even worse on systems that only have ipRouteTable support. If we really care about interoperable management applications, then we need to spell out very clearly that an IP version independent variant of the ipCidrRouteTable is only applicable on devices where the complete forwarding information can be represented in the ipCidrRouteTable. (And it is my understanding that for example a recent Linux box would not fit into this category.) We can try to improve this by adding more stuff into the index. However, we will end up with something that is getting even harder to implement correctly. And we all know that retrieving routing tables of non-trivial size via SNMP is already one of the slowest operations you can do on some boxes. So while I in general like incremental approaches, I am not sure this really works out in the particular case of the IP-FORWARD-MIB. /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 Oct 8 16:00:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98N0j29006803; Tue, 8 Oct 2002 16:00:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98N0iFZ006802; Tue, 8 Oct 2002 16:00:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98N0f29006795 for ; Tue, 8 Oct 2002 16:00:41 -0700 (PDT) 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 g98N0jPG018773 for ; Tue, 8 Oct 2002 16:00:45 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08331 for ; Tue, 8 Oct 2002 17:00:39 -0600 (MDT) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g98N0Wur023145; Tue, 8 Oct 2002 19:00:32 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 8 Oct 2002 19:00:20 -0400 Message-ID: <3DA362EA.CB422C1A@nc.rr.com> Date: Tue, 08 Oct 2002 18:57:46 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: mrm@riverstonenet.com, mrw@windriver.com, ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, bwijnen@lucent.com, ipv6mib@ibr.cs.tu-bs.de, sob@harvard.edu, mankin@isi.edu, mathis@psc.edu, narten@us.ibm.com, deering@cisco.com, hinden@iprg.nokia.com Subject: Re: Fwd: [ipv6mib] So, where were we? References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <20021004190814.GD2627@riverstonenet.com> <200210082148.g98Lm1wG029967@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juergen, So, should we look at trying to simplify the indices for the tables? That would seem like the logical thing to me. Brian Juergen Schoenwaelder wrote: > > >>>>> Michael MacFaden writes: > > Michael> Given the history of the IP-FORWARD-MIB: ipRouteTable, > Michael> ipForwardTable, and the ipCidrRouteTable a minimalist > Michael> approach might mean we have a higher probability that can get > Michael> this new work to full standard. > > The problem with the IP-FORWARD-MIB is that many systems use > forwarding bases which are much richer than what the indexing allows > to report. On such systems, implementing the ipCidrRouteTable (and the > ipRouteTable) means to report only a subset of the real forwarding > information. Hence, management applications which try to interpret > these MIB tables are kind of fooled. This is of course even worse on > systems that only have ipRouteTable support. > > If we really care about interoperable management applications, then we > need to spell out very clearly that an IP version independent variant > of the ipCidrRouteTable is only applicable on devices where the > complete forwarding information can be represented in the > ipCidrRouteTable. (And it is my understanding that for example a > recent Linux box would not fit into this category.) > > We can try to improve this by adding more stuff into the index. > However, we will end up with something that is getting even harder to > implement correctly. And we all know that retrieving routing tables of > non-trivial size via SNMP is already one of the slowest operations you > can do on some boxes. > > So while I in general like incremental approaches, I am not sure this > really works out in the particular case of the IP-FORWARD-MIB. > > /js > > -- > Juergen Schoenwaelder > -- > !! This message is brought to you via the `ipv6mib' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust > !! your settings, send a mail message to > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ipv6mib. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 16:58:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Nw229007175; Tue, 8 Oct 2002 16:58:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g98Nw28q007174; Tue, 8 Oct 2002 16:58:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g98Nvx29007167 for ; Tue, 8 Oct 2002 16:57:59 -0700 (PDT) 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 g98Nw3PG003203 for ; Tue, 8 Oct 2002 16:58:03 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09082 for ; Tue, 8 Oct 2002 16:57:57 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KNGG6WR7229030VA@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 9 Oct 2002 09:43:26 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B7AC820006; Wed, 09 Oct 2002 09:43:25 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 6425220020; Wed, 09 Oct 2002 09:43:17 +1000 (EST) Date: Wed, 09 Oct 2002 09:43:12 +1000 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: Vladislav Yasevich Cc: James Kempf , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DA36D90.1040402@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <3DA315AA.1000408@hp.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Vlad, I'm not sure that there is a requirement to use a fastra flag. There may be situations where multiple nodes come up on a link in the duration between multicast advertisements but this may be handled by the MAX_FAST_RAS being set high enough to handle this. In the case where many nodes come up on the link, it may be more effective to schedule a multicast RA in any case. I'm pretty sure that there's no problem on a network configured for fastra to give a few of the advertisements to non-mobile nodes. I believe that the presence of an 'F' bit in a router solicitation was discussed when the FastRA came up. In that solution, nodes desiring FastRA (MIPv6 MN's?) set the bit in every RS, since they could not determine whether the network supported FastRA or not, or (possibly) where they were (otherwise they wouldn't be sending the RS). If the bit is used, why wouldn't anyone just ask for fast response anyway? Isn't it reasonable to expect that all nodes desire fastest possible autoconfiguration? I don't see any reason to create an optimization which only applies to especially configured subnets (access networks?) and then tell people not to implement it in clients, since it's for MIPv6 mobile nodes only. Greg Daley Vladislav Yasevich wrote: > James > > I think that the draft is missing a trigger mechanism for a fast RA > response. What I mean is, that if any node not requiring a fast RA > joins the link, it will use up a fast RA that will potentially cause > delays for a node that would really like a fast answer. > > You could take one of the reserved bits from the RS (there are 32 of them) > and turn it in to the fast RA flag. The node that would really like > a fast answer must set the flag. The flag will be ignored by routers > that do not support fast RAs (according to 2461). > > This doesn't get rid of the malicious node consuming all of the fast > RAs, but it provides the ablility to send the RAs sparingly. > > -vlad > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 17:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g990hm29007402; Tue, 8 Oct 2002 17:43:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g990hmqv007401; Tue, 8 Oct 2002 17:43:48 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g990hj29007394 for ; Tue, 8 Oct 2002 17:43:45 -0700 (PDT) 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 g990hnMq020431 for ; Tue, 8 Oct 2002 17:43:49 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03822 for ; Tue, 8 Oct 2002 18:43:44 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.37]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA12871; Tue, 8 Oct 2002 17:42:25 -0700 (PDT) Message-Id: <5.1.0.14.2.20021008202814.030f11f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Oct 2002 20:36:26 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Robert Elz , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com In-Reply-To: <3DA31C6A.2030107@nc.rr.com> References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The more I think about it, the more I realize that "automagically" >creating the subnet-local scope zone id isn't going to work. >Especially with multiple prefixes per interface. So, this would be consistent with the suggestion that we change the Addr Arch document to list subnet-local and larger scopes as administratively defined (instead of just admin-local and higher)? Another possibility is that we could default to a non-multi-link subnet case and declare the default to be subnet-local scope == link-local scope. >>These are questions that need to be answered in the scoped address >>architecture. > >I think the addressing architecture needs to address the comment >on automatically creating the subnet-local zone id. This might be somewhat difficult, since I don't think that the concept of zone IDs is mentioned in the Addr Arch. >>I think it would be a reasonable default for a router that is >>configured with the same prefix on two interfaces to assume that >>those interfaces are on the same link (same link-local zone), and >>in the same subnet-local zone. > >But if they aren't on the same link, forwarding could break. So, does this mean that routers can't automagically configure link-local zone IDs, either? I had always assumed that two links with the same prefix would be in the same link-local zone. Is that an invalid assumption? >>In other words, I think that routers should default to the >>single-link subnet case, unless mutli-link subnetting has been >>explicitly configured. > >This is slightly different than assuming that the interfaces are >on the same link. If the router treats them as unique prefixes, >then forwarding and routing should work. How would routing and forwarding work? If the router thinks that it has two "unique" unicast prefixes that are both prefix1::/64, how will it know where to send a packet to prefix1::1? Without explicit host routes (which is the solution that Steve preferred in the multi-link subnet case), there is no way to know whether or not to forward a packet to that address. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 8 21:08:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9948i29007923; Tue, 8 Oct 2002 21:08:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9948h7i007922; Tue, 8 Oct 2002 21:08:43 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9948e29007915; Tue, 8 Oct 2002 21:08:40 -0700 (PDT) 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 g9948hMq025176; Tue, 8 Oct 2002 21:08:44 -0700 (PDT) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA21002; Tue, 8 Oct 2002 22:08:33 -0600 (MDT) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id g9944hDr015046; Wed, 9 Oct 2002 09:34:47 +0530 Message-ID: <002201c26f49$e02e1f50$b202a8c0@iwave120> From: "Anurag Uxa" To: "Tony Hain" , "Pekka Savola" Cc: , References: Subject: Query about automatic tunneling and ND Date: Wed, 9 Oct 2002 09:40:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Mr. Tony and all I have two queries . Can you pls give me the details. and tell me about some usefull document . Questions: 1. HOST1 and HOST2 are in different networks and having IPv6 addresses HOST1 send one tunneled IPV4 packet to the HOST2 (Before sending the tunneled packet out, Will the HOST1 send tunneled mulitcast NS to HOST2 ?) 2. Is Automatic tunnels always unidirectional or only for following condition [Neighbor Discovery and Stateless Address Autoconfiguration] ? P.S: RFC-2893 Automatic tunnels and unidirectional configured tunnels are considered to be unidirectional. Thus the only aspects of Neighbor Discovery [7] and Stateless Address Autoconfiguration [5] that apply to these tunnels is the formation of the link-local address. Thanks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IF U FIND SOME ONE WITHOUT A SMILE,GIVE ONE OF YOUR'S Anurag Uxa IWave Embedded systems Bangalore ph.6786243/5 extn :210 DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 21:55:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g994tb29008092; Tue, 8 Oct 2002 21:55:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g994taoF008091; Tue, 8 Oct 2002 21:55:36 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g994tW29008084 for ; Tue, 8 Oct 2002 21:55:32 -0700 (PDT) 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 g994taMq001183 for ; Tue, 8 Oct 2002 21:55:36 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18055 for ; Tue, 8 Oct 2002 21:55:27 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 08 Oct 2002 21:55:21 -0700 Reply-To: From: "Tony Hain" To: "'Anurag Uxa'" , "'Pekka Savola'" Cc: , Subject: RE: Query about automatic tunneling and ND Date: Tue, 8 Oct 2002 21:55:10 -0700 Message-ID: <088601c26f50$0dfb8750$011aa8c0@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.3416 Importance: Normal In-Reply-To: <002201c26f49$e02e1f50$b202a8c0@iwave120> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g994tW29008085 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anurag Uxa wrote: > Dear Mr. Tony and all > > I have two queries . Can you pls give me the details. and > tell me about some usefull document . > > Questions: > 1. > HOST1 and HOST2 are in different networks and having IPv6 > addresses HOST1 send one tunneled IPV4 packet IPV6 UDP packet> to the HOST2 > (Before sending the tunneled packet out, Will the > HOST1 send tunneled mulitcast NS to HOST2 ? Confirmation>) No, there is no need for NS because the necessary 'link' reachability information is already imbedded in the IPv6 address. > > 2. > Is Automatic tunnels always unidirectional or only for > following condition [Neighbor Discovery and Stateless Address > Autoconfiguration] ? Yes they are always unidirectional. > > P.S: RFC-2893 > Automatic tunnels and unidirectional configured tunnels are > considered to be unidirectional. Thus the only aspects of Neighbor > > Discovery [7] and Stateless Address Autoconfiguration [5] > that apply to these tunnels is the formation of the > link-local address. Don't spend too much time on 2893 type automatic tunnels. The replacement http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt has removed them for lack of ability to scale well. Spend more time on RFC 3056, http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-04.txt, & http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-08.txt Tony > > > > > > Thanks > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > IF U FIND SOME ONE WITHOUT A SMILE,GIVE ONE OF YOUR'S > > Anurag Uxa > IWave Embedded systems > Bangalore > ph.6786243/5 extn :210 > > > > DISCLAIMER: > > This e-mail and any attachment (s) is for authorised use by > the intended recipient (s) only. It may contain proprietary > material, confidential information and/or be subject to the > legal privilege of iWave Systems Technologies Private > Limited. If you have received this message in error, please > notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly > prohibited from retaining, using, copying, alerting or > disclosing the content of this message. Thank you for your > co-operation. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 9 01:20:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g998K529008923; Wed, 9 Oct 2002 01:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g998K5mn008922; Wed, 9 Oct 2002 01:20:05 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g998K229008915 for ; Wed, 9 Oct 2002 01:20:02 -0700 (PDT) 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 g998K7Mq002074 for ; Wed, 9 Oct 2002 01:20:07 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26567 for ; Wed, 9 Oct 2002 02:20:01 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g998JaCG028210; Wed, 9 Oct 2002 17:19:37 +0900 (KST) Message-ID: <019f01c26f6f$2b81e020$e829024b@talleyrand> From: "JinHyeock Choi" To: "James Kempf" , References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 9 Oct 2002 17:37:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g998K229008916 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James Kempf wrote > If the mobile node is > capable of detecting when the link changes, it can immediately send an RS rather > than wait for a multicast RA. According to RFC 2461, mobile host should not send RS immediately. Before sending RS, it should execute random delay like below. "Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure." Are you suggesting that above term should be loosened too? I wonder whether it is good idea to change current Neighbor Discovery protocol that much. I am afraid there may be side effect like RA overabundance. Most people will agree that Movement Detection mechanism should be improved. It takes too much time for mobile node to detect link-change under current Neighbor Discovery protocol. Hence we need to consider the following 2 items. 1) How to improve Movement Detection Algorithm? 2) How to incorporate the result of 1) to current Mobile IPv6 work? For 2), MIPv6 implementators should be provided of the results of 1). It will be useful to produce an informative draft and make implementators aware of it. For 1), I think more discussion is needed. And I have proposed an alternative method. In the proposal, AP caches Router Advertisement message and sends it to a new mobile node as soon as L2 association is made. You can find more details in below. http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 04:16:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99BGG29009640; Wed, 9 Oct 2002 04:16:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99BGF7b009639; Wed, 9 Oct 2002 04:16:15 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99BG829009622 for ; Wed, 9 Oct 2002 04:16:08 -0700 (PDT) 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 g99BGDMq024218 for ; Wed, 9 Oct 2002 04:16:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07719 for ; Wed, 9 Oct 2002 05:16:03 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09833; Wed, 9 Oct 2002 07:13:57 -0400 (EDT) Message-Id: <200210091113.HAA09833@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-ogura-ipv6-mapos-01.txt Date: Wed, 09 Oct 2002 07:13:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Version 6 over MAPOS Author(s) : T. Ogura, M. Maruyama, T. Yoshida Filename : draft-ogura-ipv6-mapos-01.txt Pages : 12 Date : 2002-10-8 Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over SONET/SDH. This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 neighbor discovery messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ogura-ipv6-mapos-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-ogura-ipv6-mapos-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-ogura-ipv6-mapos-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: <2002-10-8153917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ogura-ipv6-mapos-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ogura-ipv6-mapos-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-8153917.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 05:08:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99C8h29009792; Wed, 9 Oct 2002 05:08:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99C8hhK009791; Wed, 9 Oct 2002 05:08:43 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99C8d29009784 for ; Wed, 9 Oct 2002 05:08:39 -0700 (PDT) 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 g99C8jMq029551 for ; Wed, 9 Oct 2002 05:08:45 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17584 for ; Wed, 9 Oct 2002 05:08:39 -0700 (PDT) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g99C7jiZ023054; Wed, 9 Oct 2002 08:07:45 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 9 Oct 2002 08:07:53 -0400 Message-ID: <3DA41CCA.3080007@nc.rr.com> Date: Wed, 09 Oct 2002 08:10:50 -0400 From: Brian Haberman Organization: No Organization Here 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: Margaret Wasserman CC: Robert Elz , Steve Deering , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <5.1.0.14.2.20021006102311.063c5950@mail.windriver.com> <20020924034443.238BC18E3@thrintun.hactrn.net> <200210021443.g92Ehiv07993@cichlid.adsl.duke.edu> <20021002210106.D003418E6@thrintun.hactrn.net> <5.1.0.14.2.20021008075012.0641c5e0@mail.windriver.com> <5.1.0.14.2.20021008082745.063cbd90@mail.windriver.com> <5.1.0.14.2.20021008202814.030f11f0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > >> The more I think about it, the more I realize that "automagically" >> creating the subnet-local scope zone id isn't going to work. >> Especially with multiple prefixes per interface. > > > So, this would be consistent with the suggestion that we > change the Addr Arch document to list subnet-local and larger > scopes as administratively defined (instead of just admin-local > and higher)? Yes. Given the issues with magically setting the subnet-local zone id when multiple prefixes are enabled on an interface I would agree with that change. Though, I would like to be able to do automatic configuration of subnet zone ids if only one global prefix is configured per interface. :) That would be nice for the zero-config router scenario using multi-link subnets. > > Another possibility is that we could default to a non-multi-link > subnet case and declare the default to be subnet-local scope > == link-local scope. We may need this as well. Typically, the default behavior for any less than global scope zone id is that all interfaces are in the same zone. I don't think we want that behavior with subnet-local, it should default to being equivalent to link-local. > >>> These are questions that need to be answered in the scoped address >>> architecture. >> >> >> I think the addressing architecture needs to address the comment >> on automatically creating the subnet-local zone id. > > > This might be somewhat difficult, since I don't think that the > concept of zone IDs is mentioned in the Addr Arch. If the change is made that subnet-local must be administratively configured, you don't need to mention zone ids in the addr arch. > >>> I think it would be a reasonable default for a router that is >>> configured with the same prefix on two interfaces to assume that >>> those interfaces are on the same link (same link-local zone), and >>> in the same subnet-local zone. >> >> >> But if they aren't on the same link, forwarding could break. > > > So, does this mean that routers can't automagically configure > link-local zone IDs, either? I had always assumed that two links > with the same prefix would be in the same link-local zone. Is > that an invalid assumption? It is if you believe in multi-link subnets. Otherwise, your assumption works fine and my comment is invalid. Now, do we want to say (somewhere) that in order to identify multi-link subnets: - the prefixes must match - the subnet zone ids must match This would give us the ability to identify the link-local == subnet-local case from the subnet-local > link-local case. > >>> In other words, I think that routers should default to the >>> single-link subnet case, unless mutli-link subnetting has been >>> explicitly configured. >> >> >> This is slightly different than assuming that the interfaces are >> on the same link. If the router treats them as unique prefixes, >> then forwarding and routing should work. > > > How would routing and forwarding work? If the router thinks that > it has two "unique" unicast prefixes that are both prefix1::/64, how > will it know where to send a packet to prefix1::1? Without > explicit host routes (which is the solution that Steve preferred in > the multi-link subnet case), there is no way to know whether or > not to forward a packet to that address. Host routes would work. Another possibility (though I haven't thought it all the way through) would be to utilize NDP by sending out NS's on both interfaces. This doesn't work if prefix1::1 exists on both nets. 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 Oct 9 06:22:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99DMp29009977; Wed, 9 Oct 2002 06:22:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99DMoYV009976; Wed, 9 Oct 2002 06:22:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99DMl29009969 for ; Wed, 9 Oct 2002 06:22:47 -0700 (PDT) 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 g99DMqMq012333 for ; Wed, 9 Oct 2002 06:22:52 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09857 for ; Wed, 9 Oct 2002 07:22:47 -0600 (MDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 9 Oct 2002 15:22:46 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26F96.F47E48BB" X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt Date: Wed, 9 Oct 2002 15:22:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt Thread-Index: AcJvlvYrSVGX5ewvTSWIdrVQDr+jWw== From: "NOISETTE Yoann FTRD/DMI/CAE" To: , , , X-OriginalArrivalTime: 09 Oct 2002 13:22:46.0545 (UTC) FILETIME=[F4F7C010:01C26F96] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C26F96.F47E48BB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've recently published an ID (see below), which aims at identifying the = requirements to deploy IPv6 unmanaged networks, from an ISP point of = view. This work encompasses topics that are (could be) addressed in the = ipv6, zeroconf WG and also in the current zerouter discussions. = Moreover, though v6ops appears in the title, I'm now convinced (after = the interim meeting resolutions) that this work doesn't fit in the mould = of this WG.=20 Nevertheless, this ID intends to identify the requirements which could = lead to the definition of new protocols, mechanisms or BCP in the = aforementioned context. As it is a first shot that needs to be = completed/commented, any feedback will be very welcome, if it is = considered of interest for any of the WG or mailing list quoted above. Yoann=20 -----Message d'origine----- De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Envoy=E9 : lundi 30 septembre 2002 13:45 Cc : ipng@sunroof.eng.sun.com; zeroconf@merit.edu Objet : I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : ISP requirements for IPv6 unmanaged networks Author(s) : Y. Noisette Filename : draft-noisette-v6ops-unmannet-isp-reqts-00.txt Pages : 0 Date : 2002-9-27 =09 This document proposes to identify the elementary network functions = required to automatically deploy an IPv6 home network, i.e. with the = minimum (and ideally not a single) intervention from any administrator = or any user. The next generation Internet Protocol, IPv6, is expected to = being deployed in environments such as homes and SOHOs. However, most of = the people making use of the Internet at home don't have enough = knowledge to set up on their own the network and services. Therefore, = this document exposes the requirements necessary to ease such a = deployment, from an ISP point of view. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-noisette-v6ops-unmannet-isp-req= ts-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-noisette-v6ops-unmannet-isp-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-noisette-v6ops-unmannet-isp-reqts-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. NOISETTE Yoann &francetelecom R&D DMI/SIR/IPI 42, rue des Coutures - BP 6243 14066 CAEN Cedex 4 - FRANCE * : +33 (0)2.31.75.90.48 * : +33 (0)2.31.73.56.26 * mailto:yoann.noisette@francetelecom.com ------_=_NextPart_001_01C26F96.F47E48BB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt

Hi,

I've recently published an ID (see = below), which aims at identifying the requirements to deploy IPv6 = unmanaged networks, from an ISP point of view. This work encompasses = topics that are (could be) addressed in the ipv6, zeroconf WG and also = in the current zerouter discussions. Moreover, though v6ops appears in = the title, I'm now convinced (after the interim meeting resolutions) = that this work doesn't fit in the mould of this WG.

Nevertheless, this ID intends to = identify the requirements which could lead to the definition of new = protocols, mechanisms or BCP in the aforementioned context. As it is a = first shot that needs to be completed/commented, any feedback will be = very welcome, if it is considered of interest for any of the WG or = mailing list quoted above.

Yoann

-----Message = d'origine-----
De : Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org<= /A>]
Envoy=E9 : lundi 30 septembre = 2002 13:45
Cc : ipng@sunroof.eng.sun.com; = zeroconf@merit.edu
Objet : I-D = ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt


A New Internet-Draft is available = from the on-line Internet-Drafts directories.


        Title   =         : ISP requirements for IPv6 = unmanaged networks
        Author(s)       : Y. = Noisette
        Filename        = : draft-noisette-v6ops-unmannet-isp-reqts-00.txt
        Pages   =         : 0
        Date    =         : 2002-9-27
       =20
This document proposes to = identify the elementary network functions required to automatically = deploy an IPv6 home network, i.e. with the minimum (and ideally not a = single) intervention from any administrator or any user. The next = generation Internet Protocol, IPv6, is expected to being deployed in = environments such as homes and SOHOs. However, most of the people making = use of the Internet at home don't have enough knowledge to set up on = their own the network and services. Therefore, this document exposes the = requirements necessary to ease such a deployment, from an ISP point of = view.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-noisette-v6o= ps-unmannet-isp-reqts-00.txt

To remove yourself from the IETF = Announcement list, send a message to
ietf-announce-request with the = word unsubscribe in the body of the message.

Internet-Drafts are also = available by anonymous FTP. Login with the username
"anonymous" and a = password of your e-mail address. After logging in,
type "cd = internet-drafts" and then
        "get = draft-noisette-v6ops-unmannet-isp-reqts-00.txt".

A list of Internet-Drafts = directories can be found in
http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/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-noisette-v6ops-unmannet-isp-reqts-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will = enable a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.

NOISETTE Yoann
 &francetelecom R&D

              DMI/SIR/IPI
      42, rue des Coutures - BP 6243
      14066 CAEN Cedex 4 - = FRANCE

( : +33 (0)2.31.75.90.48    2 : +33 (0)2.31.73.56.26
* mailto:yoann.noisette@fr= ancetelecom.com


------_=_NextPart_001_01C26F96.F47E48BB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 07:07:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99E7p29010318; Wed, 9 Oct 2002 07:07:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99E7pmF010317; Wed, 9 Oct 2002 07:07:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99E7m29010310 for ; Wed, 9 Oct 2002 07:07:48 -0700 (PDT) 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 g99E7rPG000547 for ; Wed, 9 Oct 2002 07:07:53 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07949 for ; Wed, 9 Oct 2002 08:07:47 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 63377374A; Wed, 9 Oct 2002 09:07:47 -0500 (CDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 4EE191344; Wed, 9 Oct 2002 09:07:46 -0500 (CDT) Message-ID: <3DA43831.7090102@hp.com> Date: Wed, 09 Oct 2002 10:07:45 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <3DA315AA.1000408@hp.com> <3DA36D90.1040402@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Greg Daley wrote: > Hi Vlad, > > I'm not sure that there is a requirement to use a fastra flag. > > There may be situations where multiple nodes come up on a link > in the duration between multicast advertisements but this may be > handled by the MAX_FAST_RAS being set high enough to handle this. > In the case where many nodes come up on the link, it may > be more effective to schedule a multicast RA in any case. This is really the situation. When the nodes that come up really need a ultra fast configuration they can request the fast RA. When the nodes don't care, multiple solicits may answered with a single multicast RA. > > I'm pretty sure that there's no problem on a network configured > for fastra to give a few of the advertisements to non-mobile nodes. Yes, but I consider that wasting resources that could be better used otherwise. > > I believe that the presence of an 'F' bit in a router solicitation > was discussed when the FastRA came up. In that solution, nodes > desiring FastRA (MIPv6 MN's?) set the bit in every RS, since they > could not determine whether the network supported FastRA or not, > or (possibly) where they were (otherwise they wouldn't be sending the > RS). > > If the bit is used, why wouldn't anyone just ask for fast response > anyway? Isn't it reasonable to expect that all nodes desire > fastest possible autoconfiguration? Not really. Most stationarry nodes (my workstation, file server, etc...) don't really need the fast RAs. They work fine with basic ND mechanisms. The goal behind the Fast RA draft, as I see it, is to help mobile nodes identify new links that became available. > > I don't see any reason to create an optimization which only applies > to especially configured subnets (access networks?) and then tell > people not to implement it in clients, since it's for MIPv6 mobile > nodes only. No, we can't tell people not to implement them. Anyone can implement anything. It's just that it has to be implemented to be used. The way the draft is written right now, a node that may not gain the full benefit of the fast RA may get a fast response. That may lead to condition where a node that really wants a fast RA to get a delayed multicast RA defeating the point of the draft. -vlad > > Greg Daley > > > Vladislav Yasevich wrote: > >> James >> >> I think that the draft is missing a trigger mechanism for a fast RA >> response. What I mean is, that if any node not requiring a fast RA >> joins the link, it will use up a fast RA that will potentially cause >> delays for a node that would really like a fast answer. >> >> You could take one of the reserved bits from the RS (there are 32 of >> them) >> and turn it in to the fast RA flag. The node that would really like >> a fast answer must set the flag. The flag will be ignored by routers >> that do not support fast RAs (according to 2461). >> >> This doesn't get rid of the malicious node consuming all of the fast >> RAs, but it provides the ablility to send the RAs sparingly. >> >> -vlad >> >> > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 09:04:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99G4Q29010648; Wed, 9 Oct 2002 09:04:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99G4QuX010647; Wed, 9 Oct 2002 09:04:26 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99G4M29010640 for ; Wed, 9 Oct 2002 09:04:22 -0700 (PDT) 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 g99G4SMq011131 for ; Wed, 9 Oct 2002 09:04:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14583 for ; Wed, 9 Oct 2002 10:04:21 -0600 (MDT) Message-ID: <00bd01c26fad$451b7d50$056015ac@T23KEMPF> From: "James Kempf" To: "Brett Pentland" , "JinHyeock Choi" Cc: References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <019f01c26f6f$2b81e020$e829024b@talleyrand> <3DA3F4B8.841A6EBD@monash.edu> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 9 Oct 2002 09:02:28 -0700 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 > I'm not sure that we are loosening that. The rest of the quoted > paragraph reads: > > "If a host has already performed > a random delay since the interface became (re)enabled (e.g., as part > of Duplicate Address Detection [ADDRCONF]) there is no need to delay > again before sending the first Router Solicitation message." > > I took the paragraph as meaning that the RS should be delayed when the > host first comes up to avoid synchronization with other devices after > some abnormal event, but that movement is part of normal operation, not > expected to be synchronized with other hosts and so the delay is not > required. Any thoughts? > Agree. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 11:02:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99I2829011504; Wed, 9 Oct 2002 11:02:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99I28jb011503; Wed, 9 Oct 2002 11:02:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99I2429011496 for ; Wed, 9 Oct 2002 11:02:04 -0700 (PDT) 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 g99I29PG025602 for ; Wed, 9 Oct 2002 11:02:09 -0700 (PDT) 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 MAA15928 for ; Wed, 9 Oct 2002 12:02:03 -0600 (MDT) Message-ID: <005d01c26fbc$f325a2e0$3c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Brett Pentland" , "JinHyeock Choi" Cc: References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <019f01c26f6f$2b81e020$e829024b@talleyrand> <3DA3F4B8.841A6EBD@monash.edu> <00bd01c26fad$451b7d50$056015ac@T23KEMPF> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 9 Oct 2002 10:54:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm not sure that we are loosening that. The rest of the quoted > > paragraph reads: > > > > "If a host has already performed > > a random delay since the interface became (re)enabled (e.g., as part > > of Duplicate Address Detection [ADDRCONF]) there is no need to delay > > again before sending the first Router Solicitation message." > > > > I took the paragraph as meaning that the RS should be delayed when the > > host first comes up to avoid synchronization with other devices after > > some abnormal event, but that movement is part of normal operation, not > > expected to be synchronized with other hosts and so the delay is not > > required. Any thoughts? Sometimes handovers can also be synchronized (to some extent) among a set of mobile nodes, for example when they are traveling in the same transportation vehicle. alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 11:06:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99I5x29011571; Wed, 9 Oct 2002 11:05:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99I5x1p011570; Wed, 9 Oct 2002 11:05:59 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99I5u29011563 for ; Wed, 9 Oct 2002 11:05:56 -0700 (PDT) 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 g99I61Mq014783 for ; Wed, 9 Oct 2002 11:06:01 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01690 for ; Wed, 9 Oct 2002 11:05:56 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g99I1uq23207; Wed, 9 Oct 2002 11:01:57 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g99I24A18590; Wed, 9 Oct 2002 13:02:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 13:01:51 -0500 Message-ID: From: "Mohamed Khalil" To: Brett Pentland Cc: ipng@sunroof.eng.sun.com, "'James Kempf'" , JinHyeock Choi Subject: RE: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 9 Oct 2002 13:01:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FBD.F1239BE0" 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_01C26FBD.F1239BE0 Content-Type: text/plain I'm not sure that we are loosening that. The rest of the quoted paragraph reads: "If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message." I took the paragraph as meaning that the RS should be delayed when the host first comes up to avoid synchronization with other devices after some abnormal event, but that movement is part of normal operation, not expected to be synchronized with other hosts and so the delay is not required. Any thoughts? You are right ------_=_NextPart_001_01C26FBD.F1239BE0 Content-Type: text/html RE: Changing RS Reply Timing for Mobile IPv6


 I'm not sure that we are loosening that.  The rest of the quoted
 paragraph reads:
 
   "If a host has already performed
    a random delay since the interface became (re)enabled (e.g., as part
    of Duplicate Address Detection [ADDRCONF]) there is no need to delay
    again before sending the first Router Solicitation message."
 
 I took the paragraph as meaning that the RS should be delayed when the
 host first comes up to avoid synchronization with other devices after
 some abnormal event, but that movement is part of normal operation,
 not expected to be synchronized with other hosts and so the delay is
 not required.  Any thoughts?
 

You are right

------_=_NextPart_001_01C26FBD.F1239BE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 12:18:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JIJ29012397; Wed, 9 Oct 2002 12:18:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99JIIv4012396; Wed, 9 Oct 2002 12:18:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JIF29012389 for ; Wed, 9 Oct 2002 12:18:15 -0700 (PDT) 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 g99JIKPG016597 for ; Wed, 9 Oct 2002 12:18:21 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29875 for ; Wed, 9 Oct 2002 13:18:15 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 12:18:11 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Oct 2002 12:18:10 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 12:18:10 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 12:18:10 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 9 Oct 2002 12:18:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Date: Wed, 9 Oct 2002 12:18:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt thread-index: AcJvjS8WKK+H0iu4S3yVJos+x+AgUQAOi/2w From: "Dave Thaler" To: "Brian Haberman" Cc: X-OriginalArrivalTime: 09 Oct 2002 19:18:09.0908 (UTC) FILETIME=[9AAEBB40:01C26FC8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99JIF29012390 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > >> The more I think about it, the more I realize that "automagically" > >> creating the subnet-local scope zone id isn't going to work. > >> Especially with multiple prefixes per interface. Why not? Can you elaborate? Shouldn't it always be true that if any two interfaces have the same (non-link-local) subnet prefix, then their subnet-local zone id MUST be the same? > > So, this would be consistent with the suggestion that we > > change the Addr Arch document to list subnet-local and larger > > scopes as administratively defined (instead of just admin-local > > and higher)? > > Yes. Given the issues with magically setting the subnet-local > zone id when multiple prefixes are enabled on an interface I > would agree with that change. I would disagree with that change. > > Another possibility is that we could default to a non-multi-link > > subnet case and declare the default to be subnet-local scope > > == link-local scope. > > We may need this as well. Typically, the default behavior for > any less than global scope zone id is that all interfaces are > in the same zone. I don't think we want that behavior with > subnet-local, it should default to being equivalent to link-local. I agree. This also is what we implemented. > >>> In other words, I think that routers should default to the > >>> single-link subnet case, unless mutli-link subnetting has been > >>> explicitly configured. I agree with one important clarification. "Explicitly configured" != "administratively configured". The zero-config counter argument is a box that is labeled as having its default configuration be that interfaces are on the same subnet different but different links (e.g. guaranteed to be different because they're different media, like an 802.11 access point with a wired Ethernet link). Here the explicitly configuration was done by the factory, not by the admin. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 12:28:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JSu29012521; Wed, 9 Oct 2002 12:28:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99JSune012520; Wed, 9 Oct 2002 12:28:56 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99JSr29012513 for ; Wed, 9 Oct 2002 12:28:53 -0700 (PDT) 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 g99JSwMq011379 for ; Wed, 9 Oct 2002 12:28:59 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28627 for ; Wed, 9 Oct 2002 12:28:53 -0700 (PDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99JShsn015656; Wed, 9 Oct 2002 15:28:45 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA02144; Wed, 9 Oct 2002 15:29:14 -0400 (EDT) Date: Wed, 9 Oct 2002 15:28:41 -0400 To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: multihomed host Message-ID: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 25 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have one question about multihomed host. In the multi6 WG charter, there is the following definition for multihomed "site": A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc. Is there any definition for multihomed "host"? Of cource, a definition would be quickly made by just replacing a word "site" in the above definition with "host", but please let me know if there is other definition. Regards, Yoshihiro Ohba -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 12:44:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99Ji129012638; Wed, 9 Oct 2002 12:44:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99Ji1AQ012637; Wed, 9 Oct 2002 12:44:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99Jhv29012630 for ; Wed, 9 Oct 2002 12:43:57 -0700 (PDT) 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 g99Ji2PG022604 for ; Wed, 9 Oct 2002 12:44:03 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15854 for ; Wed, 9 Oct 2002 13:43:57 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00648; Wed, 9 Oct 2002 12:42:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Oct 2002 15:42:47 -0400 To: Yoshihiro Ohba From: Margaret Wasserman Subject: Re: multihomed host Cc: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Is there any definition for multihomed "host"? I don't know if there is an official definition, but I have usually heard the term "multihomed host" used to refer to multi-interface systems that do not function as routers (i.e. they don't forward packets). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 13:10:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KA729012813; Wed, 9 Oct 2002 13:10:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99KA7kL012812; Wed, 9 Oct 2002 13:10:07 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KA329012805 for ; Wed, 9 Oct 2002 13:10:04 -0700 (PDT) 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 g99KA9Mq021718 for ; Wed, 9 Oct 2002 13:10:09 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16377 for ; Wed, 9 Oct 2002 14:10:03 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99K9Ssn019746; Wed, 9 Oct 2002 16:09:28 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA02292; Wed, 9 Oct 2002 16:09:58 -0400 (EDT) Date: Wed, 9 Oct 2002 16:09:20 -0400 To: Margaret Wasserman Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Message-ID: <20021009200920.GK2310@catfish> References: <20021009192841.GI2310@catfish> <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 28 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your quick response. There may be some scenario in which a single-interface host is connected to multiple ISPs on the same link, which seems to be not covered in the usual definition for "multihomed host". I don't know what to call the model, but is such a model already common? Or is there any ongoing work on this model? On Wed, Oct 09, 2002 at 03:42:47PM -0400, Margaret Wasserman wrote: > > > > > > >Is there any definition for multihomed "host"? > > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). > > Margaret > Thanks, Yoshihiro Ohba -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 13:31:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KVS29012962; Wed, 9 Oct 2002 13:31:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99KVSns012961; Wed, 9 Oct 2002 13:31:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KVO29012954 for ; Wed, 9 Oct 2002 13:31:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24133; Wed, 9 Oct 2002 16:31:29 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g99KVSgu023997; Wed, 9 Oct 2002 16:31:28 -0400 (EDT) Message-Id: <200210092031.g99KVSgu023997@thunk.east.sun.com> From: Bill Sommerfeld To: Margaret Wasserman cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host In-Reply-To: Your message of "Wed, 09 Oct 2002 15:42:47 EDT." <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Oct 2002 16:31:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). For what it's worth, I've occasionally heard the term used in an application-layer context to refer to hosts having multiple IP addresses rather than/in addition to multiple interfaces. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 13:45:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KjU29013067; Wed, 9 Oct 2002 13:45:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99KjT81013066; Wed, 9 Oct 2002 13:45:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99KjQ29013059 for ; Wed, 9 Oct 2002 13:45:26 -0700 (PDT) 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 g99KjWPG007769 for ; Wed, 9 Oct 2002 13:45:32 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28162 for ; Wed, 9 Oct 2002 13:45:26 -0700 (PDT) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g99Kjbup009823 for ; Wed, 9 Oct 2002 16:45:37 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 9 Oct 2002 16:45:23 -0400 Message-ID: <3DA49615.3010807@nc.rr.com> Date: Wed, 09 Oct 2002 16:48:21 -0400 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: >>From: Brian Haberman [mailto:bkhabs@nc.rr.com] >> >>>>The more I think about it, the more I realize that "automagically" >>>>creating the subnet-local scope zone id isn't going to work. >>>>Especially with multiple prefixes per interface. >>> > > Why not? Can you elaborate? > Shouldn't it always be true that if any two interfaces have the > same (non-link-local) subnet prefix, then their subnet-local > zone id MUST be the same? What happens to the zone ids when: 1. Interface 1 has prefix1 and prefix2 2. Interface 2 has prefix1 and prefix3 3. Interface 3 has prefix2 and prefix4 > > >>>So, this would be consistent with the suggestion that we >>>change the Addr Arch document to list subnet-local and larger >>>scopes as administratively defined (instead of just admin-local >>>and higher)? >> >>Yes. Given the issues with magically setting the subnet-local >>zone id when multiple prefixes are enabled on an interface I >>would agree with that change. > > > I would disagree with that change. > > >>>Another possibility is that we could default to a non-multi-link >>>subnet case and declare the default to be subnet-local scope >>>== link-local scope. >> >>We may need this as well. Typically, the default behavior for >>any less than global scope zone id is that all interfaces are >>in the same zone. I don't think we want that behavior with >>subnet-local, it should default to being equivalent to link-local. > > > I agree. This also is what we implemented. > > >>>>>In other words, I think that routers should default to the >>>>>single-link subnet case, unless mutli-link subnetting has been >>>>>explicitly configured. >>>> > > I agree with one important clarification. > "Explicitly configured" != "administratively configured". Totally agree. > > The zero-config counter argument is a box that is labeled as > having its default configuration be that interfaces are on the > same subnet different but different links (e.g. guaranteed > to be different because they're different media, like an > 802.11 access point with a wired Ethernet link). Here > the explicitly configuration was done by the factory, not > by the admin. Yep. 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 Oct 9 14:02:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99L2e29013187; Wed, 9 Oct 2002 14:02:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99L2e9h013186; Wed, 9 Oct 2002 14:02:40 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99L2a29013176 for ; Wed, 9 Oct 2002 14:02:37 -0700 (PDT) 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 g99L2gMq005141 for ; Wed, 9 Oct 2002 14:02:42 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20098 for ; Wed, 9 Oct 2002 15:02:37 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 14:02:36 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Oct 2002 14:02:36 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 14:02:35 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Oct 2002 14:02:35 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Wed, 9 Oct 2002 14:02:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Date: Wed, 9 Oct 2002 14:02:35 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384306@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt thread-index: AcJv1XeFWnRZjJLeRD+vT+AHFuzDsgAAUJVg From: "Dave Thaler" To: "Brian Haberman" , X-OriginalArrivalTime: 09 Oct 2002 21:02:35.0467 (UTC) FILETIME=[313F29B0:01C26FD7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99L2b29013177 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: Wednesday, October 09, 2002 1:48 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch- > v3-10.txt > > Dave Thaler wrote: > >>From: Brian Haberman [mailto:bkhabs@nc.rr.com] > >> > >>>>The more I think about it, the more I realize that "automagically" > >>>>creating the subnet-local scope zone id isn't going to work. > >>>>Especially with multiple prefixes per interface. > >>> > > > > Why not? Can you elaborate? > > Shouldn't it always be true that if any two interfaces have the > > same (non-link-local) subnet prefix, then their subnet-local > > zone id MUST be the same? > > What happens to the zone ids when: > > 1. Interface 1 has prefix1 and prefix2 > 2. Interface 2 has prefix1 and prefix3 > 3. Interface 3 has prefix2 and prefix4 According to the default rule, all three are in the same subnet-local zone. You've just chosen for some reason not to advertise some prefixes on some links. Personally, I'd put this in the category of "don't do that", just like I wouldn't recommend using using different subnet ids for different prefixes on the same link. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 15:20:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MKr29013706; Wed, 9 Oct 2002 15:20:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99MKqPP013705; Wed, 9 Oct 2002 15:20:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MKn29013698 for ; Wed, 9 Oct 2002 15:20:49 -0700 (PDT) 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 g99MKsMq026038 for ; Wed, 9 Oct 2002 15:20:55 -0700 (PDT) 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 PAA29165 for ; Wed, 9 Oct 2002 15:20:49 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 15:21:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E365@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multihomed host Thread-Index: AcJv03CVWgQrBF9MSVe0fEonzBlzQAAC4vzw From: "Michel Py" To: , "Margaret Wasserman" Cc: "Yoshihiro Ohba" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99MKn29013699 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yoshihiro Ohba wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). Here is my reading of this: 1. Multi-interface host: > Margaret Wasserman wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). I agree with Margaret. A host that has multiple interfaces connected to multiple subnets *is* a multihomed host, but... 2. A host that has multiple interfaces with addresses in the same subnet (either to increase throughput or to provide redundancy) is *not* a multihomed host. 3. Single interface, multiple address host: > Bill Sommerfeld wrote: > For what it's worth, I've occasionally heard the > term used in an application-layer context to refer > to hosts having multiple IP addresses rather than/in > addition to multiple interfaces. For v4, I agree with Bill *if* the multiple addresses belong to different subnets. For v6, this is blurry. Would you call multihomed a host that has both a link-local and a regular unicast address on the same interface? I don't think so. On the other hand, > Yoshihiro Ohba wrote: > There may be some scenario in which a single-interface > host is connected to multiple ISPs on the same link, which > seems to be not covered in the usual definition for > "multihomed host". I don't know what to call the model, > but is such a model already common? Or is there any > ongoing work on this model? This is possible as of today; a host that has multiple PA addresses is certainly considered a multihomed host. However, this alone is not a multihoming solution. 4. A host that has a single address but is part of a multihomed site: This would be the case for hosts belonging to a multihomed LIR, or the case of hosts connecting to a MHAP network. I do not call these hosts multihomed. In other words: semantically speaking, the fact that the host is connected to a multihomed router does not make the host itself multihomed, IMHO. 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 Oct 9 15:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MmW29014030; Wed, 9 Oct 2002 15:48:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99MmWLI014029; Wed, 9 Oct 2002 15:48:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MmS29014019 for ; Wed, 9 Oct 2002 15:48:29 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27727; Wed, 9 Oct 2002 18:48:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g99MmWgu025186; Wed, 9 Oct 2002 18:48:32 -0400 (EDT) Message-Id: <200210092248.g99MmWgu025186@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , "Yoshihiro Ohba" , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host In-Reply-To: Your message of "Wed, 09 Oct 2002 15:21:34 PDT." <2B81403386729140A3A899A8B39B046405E365@server2000> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Oct 2002 18:48:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For v4, I agree with Bill *if* the multiple addresses belong to > different subnets. > > For v6, this is blurry. Would you call multihomed a host that has both a > link-local and a regular unicast address on the same interface? I don't > think so. >From the point of view of what applications need to do, it's safest to assume that all V6 hosts are multiaddressed. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 15:55:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MtL29014192; Wed, 9 Oct 2002 15:55:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99MtLWA014191; Wed, 9 Oct 2002 15:55:21 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99MtI29014184 for ; Wed, 9 Oct 2002 15:55:18 -0700 (PDT) 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 g99MtNMq005333 for ; Wed, 9 Oct 2002 15:55:23 -0700 (PDT) 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 QAA28835 for ; Wed, 9 Oct 2002 16:55:11 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 15:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B04640BD192@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multihomed host Thread-Index: AcJv5i+GBJC2QX20Qf+uo/e21ejqigAAGxoA From: "Michel Py" To: Cc: "Margaret Wasserman" , "Yoshihiro Ohba" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g99MtI29014185 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bill Sommerfeld wrote: > From the point of view of what applications need to do, > it's safest to assume that all V6 hosts are multiaddressed. Strongly agree. Although multiaddressed does not necessarily mean multihomed, it is likely that part of the multihoming solution is multiadressed hosts. 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 Oct 9 16:21:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99NLh29014596; Wed, 9 Oct 2002 16:21:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99NLh06014595; Wed, 9 Oct 2002 16:21:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99NLe29014588 for ; Wed, 9 Oct 2002 16:21:40 -0700 (PDT) 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 g99NLkPG017352 for ; Wed, 9 Oct 2002 16:21:46 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04035; Wed, 9 Oct 2002 16:21:40 -0700 (PDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99NKwsn002797; Wed, 9 Oct 2002 19:20:58 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA02904; Wed, 9 Oct 2002 19:21:29 -0400 (EDT) Date: Wed, 9 Oct 2002 19:20:56 -0400 To: Michel Py Cc: sommerfeld@east.sun.com, Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Message-ID: <20021009232056.GN2310@catfish> References: <2B81403386729140A3A899A8B39B046405E365@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E365@server2000> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 24 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you all for helping me understand. I have additional question below. On Wed, Oct 09, 2002 at 03:21:34PM -0700, Michel Py wrote: > On the other hand, > > Yoshihiro Ohba wrote: > > There may be some scenario in which a single-interface > > host is connected to multiple ISPs on the same link, which > > seems to be not covered in the usual definition for > > "multihomed host". I don't know what to call the model, > > but is such a model already common? Or is there any > > ongoing work on this model? > > This is possible as of today; a host that has multiple PA addresses is > certainly considered a multihomed host. However, this alone is not a > multihoming solution. > What additional things need to be considered for this usage to become a multihoming solution? Yoshihiro Ohba -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 16:57:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99NvM29014742; Wed, 9 Oct 2002 16:57:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g99NvMFs014741; Wed, 9 Oct 2002 16:57:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g99NvI29014734 for ; Wed, 9 Oct 2002 16:57:18 -0700 (PDT) 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 g99NvNPG025350 for ; Wed, 9 Oct 2002 16:57:24 -0700 (PDT) Received: from realname ([203.254.224.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16480 for ; Wed, 9 Oct 2002 17:57:18 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H3Q00I10O4WA4@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 10 Oct 2002 09:02:56 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H3Q00HA3O4DXX@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 10 Oct 2002 09:02:37 +0900 (KST) Received: from kps ([168.219.203.152]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H3Q003FBO5AQQ@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 10 Oct 2002 09:03:10 +0900 (KST) Date: Thu, 10 Oct 2002 09:01:38 +0900 From: Pyungsoo Kim Subject: draft-lee-optimal-detect-pmtu-00.txt To: IPv6WG Message-id: <00f401c26ff0$349c7c20$98cbdba8@sec.samsung.co.kr> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_0M6kvAa2spWUB1cW85nnJw)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_0M6kvAa2spWUB1cW85nnJw) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Dear IPv6 WG: The following draft is posted newly in the drafts directory http://www.ietf.org/internet-drafts/draft-lee-optimal-detect-pmtu-00.txt Title : Optimal Detecting Increases in PMTU Author(s) : HAK GOO LEE, PYUNG SOO KIM, YOUNG KEUN KIM, CHU KYO SHIN Abstract : This document presents a new method for the detection of increases in PMTU using the newly defined Hop-by-Hop option header. To detect increases in a path's PMTU, a node does not increase its assumed PMTU unconditionally without considering network status, but measures its real PMTU, and then replaces the previous PMTU with new one. To measure node's real PMTU, the node sends the IP packet with the newly defined Hop-by-Hop option header to the destination node right before a timer expires. This can eliminate the chance of occurrence of packets being discarded and Packet Too Big messages being generated. What do you think? Pyungsoo ------------------------------------------------------------- Pyungsoo Kim Senior Engineer, Ph. D. Mobile Platform Group, Digital Media R&D Center Samsung Electronics Co., Ltd. Tel : +82-31-200-4635 Email: kimps@samsung.com URL : http://cisl.snu.ac.kr/~kps ------------------------------------------------------------- --Boundary_(ID_0M6kvAa2spWUB1cW85nnJw) Content-type: text/html; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT
Dear IPv6 WG:

The following draft is posted newly in the drafts
 
 
Title : Optimal Detecting Increases in PMTU
Author(s) : HAK GOO LEE,  PYUNG SOO KIM,  YOUNG KEUN KIM,  CHU KYO SHIN
 
Abstract :
    This document presents a new method for the detection of increases
    in PMTU using the newly defined Hop-by-Hop option header.
    To detect increases in a path's PMTU, a node does not increase its
    assumed PMTU unconditionally without considering network status,
    but measures its real PMTU, and then replaces the previous PMTU with
    new one. To measure node's real PMTU, the node sends the IP packet
    with the newly defined Hop-by-Hop option header to the destination
    node right before a timer expires. This can eliminate the chance of
    occurrence of packets being discarded and Packet Too Big messages
    being generated.
 
 
What do you think?

Pyungsoo
 
-------------------------------------------------------------
Pyungsoo Kim
Senior Engineer, Ph. D.
Mobile Platform Group, Digital Media R&D Center
Samsung Electronics Co., Ltd.
Tel  : +82-31-200-4635
Email: kimps@samsung.com
URL  : http://cisl.snu.ac.kr/~kps
-------------------------------------------------------------
--Boundary_(ID_0M6kvAa2spWUB1cW85nnJw)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 17:57:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A0vA29015140; Wed, 9 Oct 2002 17:57:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9A0vAHU015139; Wed, 9 Oct 2002 17:57:10 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A0v729015132; Wed, 9 Oct 2002 17:57:07 -0700 (PDT) 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 g9A0vCMq002626; Wed, 9 Oct 2002 17:57:12 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14757; Wed, 9 Oct 2002 18:57:06 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g9A0ujCG016602; Thu, 10 Oct 2002 09:56:50 +0900 (KST) Message-ID: <014101c26ffa$7ffe8910$e829024b@talleyrand> From: "JinHyeock Choi" To: "Brett Pentland" Cc: "James Kempf" , , References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF><019f01c26f6f$2b81e020$e829024b@talleyrand> <3DA3F4B8.841A6EBD@monash.edu> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Thu, 10 Oct 2002 10:15:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g9A0v72A015133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brett Thanks for your kind comment. As you may know, random delay of RS is 'to alleviate congestion' as the following states: " This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure." Therefore, we should examine if there will be congestion in case "mobile nodes send RS without delay when they detect link changes". Two cases come in to my attention. 1) As Alper pointed, sometimes handovers can be synchronized (to some extent) among a set of mobile nodes. In that case, there would be congestion. 2) Sometimes (abnormal) link change occurs without movement. For example, if AP (not AR) recovers from power failure or admin changes AP for new one, mobile nodes will detect link change and send RSs simultaneously. To prevent this, mobile nodes should be able to distinguish normal link change (caused by movement) from abnormal link change (caused by power failure or AP exchange). With the above reasons, I think there will be congestion without random delay. Do you think it's negligible? Regards, -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 19:02:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A22c29015910; Wed, 9 Oct 2002 19:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9A22cZJ015909; Wed, 9 Oct 2002 19:02:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A22Z29015902 for ; Wed, 9 Oct 2002 19:02:35 -0700 (PDT) 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 g9A22YPG020902 for ; Wed, 9 Oct 2002 19:02:35 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05741 for ; Wed, 9 Oct 2002 20:02:28 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KNHYWEP7GU9LVJQ7@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 10 Oct 2002 11:50:23 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 53D7912C01E; Thu, 10 Oct 2002 11:50:10 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id E7ABB12C051; Thu, 10 Oct 2002 11:50:06 +1000 (EST) Date: Thu, 10 Oct 2002 11:50:01 +1000 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: Vladislav Yasevich Cc: James Kempf , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DA4DCC9.9050503@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <00dc01c26ee7$d628e420$056015ac@T23KEMPF> <3DA315AA.1000408@hp.com> <3DA36D90.1040402@eng.monash.edu.au> <3DA43831.7090102@hp.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Vlad, Vladislav Yasevich wrote: > Greg > > Greg Daley wrote: > >> Hi Vlad, >> >> I'm not sure that there is a requirement to use a fastra flag. >> >> There may be situations where multiple nodes come up on a link >> in the duration between multicast advertisements but this may be >> handled by the MAX_FAST_RAS being set high enough to handle this. >> In the case where many nodes come up on the link, it may >> be more effective to schedule a multicast RA in any case. > > > This is really the situation. When the nodes that come up really > need a ultra fast configuration they can request the fast RA. > When the nodes don't care, multiple solicits may answered with a > single multicast RA. It really depends on your multicast advertisement interval. We're unlikely to see ANY rs's from fixed nodes within a relatively short interval (say 10s on networks supporting MN's). So the only situation where this will be a problem is if the network is just coming up, and all devices are (re?)configuring their addresses. In the unlikely event that an MN changes to that network during these few seconds, if it doesn't do the 'SHOULD wait before sending RS' which all other nodes will be doing, then it is likely to be one of the first to receive response in any case. >> I'm pretty sure that there's no problem on a network configured >> for fastra to give a few of the advertisements to non-mobile nodes. > > Yes, but I consider that wasting resources that could be better used > otherwise. Since the resource is renewed continuously, we're only talking about fallback to multicast in the case of DoS or the link coming up. >> If the bit is used, why wouldn't anyone just ask for fast response >> anyway? Isn't it reasonable to expect that all nodes desire >> fastest possible autoconfiguration? > > Not really. Most stationarry nodes (my workstation, file server, etc...) > don't really need the fast RAs. They work fine with basic ND mechanisms. > The goal behind the Fast RA draft, as I see it, is to help mobile nodes > identify new links that became available. As far as I can see, there's only an issue with sharing fastRA's: When a link comes up and multiple nodes all need access. In this case, stationary nodes are already running and are just as likely to have existing conversations as MN's. They will all need as fast a response as possible. >> I don't see any reason to create an optimization which only applies >> to especially configured subnets (access networks?) and then tell >> people not to implement it in clients, since it's for MIPv6 mobile >> nodes only. > > > No, we can't tell people not to implement them. Anyone can implement > anything. It's just that it has to be implemented to be used. > > The way the draft is written right now, a node that may not gain the > full benefit of the fast RA may get a fast response. That may lead > to condition where a node that really wants a fast RA to get a > delayed multicast RA defeating the point of the draft. I'll have to say that I really don't see a problem on links which have few fixed nodes. In the case where a router is configured especially for supporting MN's, I don't think that there is any harm in generating a fastRA even when it is not asked for. Also, I don't see the harm in explicitly requesting fastRA in RS's, so, any recommendation short of a "MUST NOT reply with fast RA to packets where 'F' bit is 0" is fine with me. I'm just trying to make minimal changes to node function. Greg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 9 19:34:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A2Yr29016111; Wed, 9 Oct 2002 19:34:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9A2Yqab016110; Wed, 9 Oct 2002 19:34:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A2Yn29016103 for ; Wed, 9 Oct 2002 19:34:49 -0700 (PDT) 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 g9A2YtPG026180 for ; Wed, 9 Oct 2002 19:34:55 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12335 for ; Wed, 9 Oct 2002 19:34:49 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9A2X1B03654; Wed, 9 Oct 2002 22:33:02 -0400 Message-Id: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> To: "James Kempf" cc: ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 In-Reply-To: Message from "James Kempf" of "Tue, 08 Oct 2002 09:29:12 PDT." <00dc01c26ee7$d628e420$056015ac@T23KEMPF> Date: Wed, 09 Oct 2002 22:33:01 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In summary, the draft amends RFC 2461 to allow at most one router on > a link to reply immediately to an RS instead of waiting a random > amount of time between 0 and MAX_RA_DELAY_TIME. The router is > allowed to reply to at most MAX_FAST_RAS since the last unsolicited > multicast is sent. If this number is exceeded, the router rolls over > to scheduling a multicast RA as soon as possible. This is intended > to avoid DoS attacks on the router. This presumably requires some per-link or per-router configuration? I.e., how does the "one" router that is allowed respond more quickly get picked? Given that, putting the words in a standards track doc seems with regards to how a collection of routers behaves seems a bit odd. I see that this document just says how this is configured is out of scope for the document.... Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router delays a random amount of time between 0 and .5 seconds before responding. So, on average, .25 seconds. That's not a terribly long delay. What exactly is the application that can't deal with this kind of a delay? Then there is more to getting link connectivity than just finding a router. You may have to generate an address, and then invoke DAD. But DAD (on an Ethernet) requires a 1 second delay. That's a much bigger factor than the RS delay. Is this not also an issue? I.e., what is so critical about getting an immediate RS but that doesn't also have an issue with some of the other ND/addrconf/DAD constants. Will addressing the RS delay alone *really* solve the problem here, and if not, shouldn't we be thinking about the more general problem and working on finding a solution that deals with all the potential delay spots? 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 Wed Oct 9 23:10:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A6AP29016652; Wed, 9 Oct 2002 23:10:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9A6APtT016651; Wed, 9 Oct 2002 23:10:25 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9A6AL29016644 for ; Wed, 9 Oct 2002 23:10:22 -0700 (PDT) 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 g9A6ARMq022737 for ; Wed, 9 Oct 2002 23:10:27 -0700 (PDT) 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 XAA06197 for ; Wed, 9 Oct 2002 23:10:22 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 23:11:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E369@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multihomed host Thread-Index: AcJv6s3SpmocDFsoSuG9IRHUzk8BuwAN8WZA From: "Michel Py" To: "Yoshihiro Ohba" Cc: , "Margaret Wasserman" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9A6AM29016645 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Yoshihiro Ohba wrote: >>> There may be some scenario in which a single-interface >>> host is connected to multiple ISPs on the same link, which >>> seems to be not covered in the usual definition for >>> "multihomed host". I don't know what to call the model, >>> but is such a model already common? Or is there any >>> ongoing work on this model? >> Michel Py wrote: >> This is possible as of today; a host that has multiple PA >> addresses is certainly considered a multihomed host. >> However, this alone is not a multihoming solution. > What additional things need to be considered for this > usage to become a multihoming solution? There is no simple answer to this question. Here is one approach: http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt 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 Oct 10 03:02:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AA2s29017456; Thu, 10 Oct 2002 03:02:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AA2saK017455; Thu, 10 Oct 2002 03:02:54 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AA2p29017448 for ; Thu, 10 Oct 2002 03:02:51 -0700 (PDT) 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 g9AA2uMq026012 for ; Thu, 10 Oct 2002 03:02:56 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09715 for ; Thu, 10 Oct 2002 03:02:51 -0700 (PDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AA2eiZ024148; Thu, 10 Oct 2002 06:02:40 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 06:02:47 -0400 Message-ID: <3DA54FB0.DA39CCEA@nc.rr.com> Date: Thu, 10 Oct 2002 06:00:16 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <2E33960095B58E40A4D3345AB9F65EC107384306@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > > > -----Original Message----- > > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > > Sent: Wednesday, October 09, 2002 1:48 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: IPv6 subnet-local addresses and > draft-ietf-ipngwg-addr-arch- > > v3-10.txt > > > > Dave Thaler wrote: > > >>From: Brian Haberman [mailto:bkhabs@nc.rr.com] > > >> > > >>>>The more I think about it, the more I realize that "automagically" > > >>>>creating the subnet-local scope zone id isn't going to work. > > >>>>Especially with multiple prefixes per interface. > > >>> > > > > > > Why not? Can you elaborate? > > > Shouldn't it always be true that if any two interfaces have the > > > same (non-link-local) subnet prefix, then their subnet-local > > > zone id MUST be the same? > > > > What happens to the zone ids when: > > > > 1. Interface 1 has prefix1 and prefix2 > > 2. Interface 2 has prefix1 and prefix3 > > 3. Interface 3 has prefix2 and prefix4 > > According to the default rule, all three are in the > same subnet-local zone. You've just chosen for some > reason not to advertise some prefixes on some links. > Personally, I'd put this in the category of "don't do that", > just like I wouldn't recommend using using different subnet > ids for different prefixes on the same link. Why are some prefixes not advertised? What happens if prefix3 is FE80:1:2:3::/64 and Interfaces 2&3 have different site-local zone ids? Then obviously you can't make all three interfaces be in the same subnet-local zone id. 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 Oct 10 05:50:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ACoF29018051; Thu, 10 Oct 2002 05:50:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ACoFDo018050; Thu, 10 Oct 2002 05:50:15 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ACoA29018043 for ; Thu, 10 Oct 2002 05:50:11 -0700 (PDT) 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 g9ACoBA28612; Thu, 10 Oct 2002 14:50:11 +0200 (MEST) Date: Wed, 9 Oct 2002 23:32:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Implementation worries about default address selection 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 > The thing is, it seems like this (IMO relatively complex) iterative > comparison algorithm must be run for every outbound packet (one might be > able to optimize a bit with connection-oriented protocols). I think connection oriented protocols effectively require that the source address (or addresses in the case of SCTP) be selected when the connection is created. Thus trying to do this for every packet would be the wrong thing in that case. For connection-less protocols where the application doesn't specify the source address in the bind() call, performance can benefit from caching the source address selected for a given destination much the same way that performance benefits from caching routing information for a given destination. > An alternative seems to be to implement some form of (unspecified -- > caching is only discussed in the context of dst address selection) > optimizations. One example of optimization could be putting the > to-be-used source address in the routing table, and refresh it always when > rtable or any address of the node changes or changes state > (deprecated/preferred, home address etc.), but these might have their own > problems. > > My worry is, is it useful to specify a mechanism for selection default > addresses that can't really be used without critical optimizations? I'm not worried about this. We have exactly the same issue for routing table lookup in hosts and routers; there is no specification that states how to implement caching schemes. 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 Oct 10 06:02:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AD2S29018106; Thu, 10 Oct 2002 06:02:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AD2SkH018105; Thu, 10 Oct 2002 06:02:28 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AD2P29018098 for ; Thu, 10 Oct 2002 06:02:25 -0700 (PDT) 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 g9AD2VMq016472 for ; Thu, 10 Oct 2002 06:02:31 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20762 for ; Thu, 10 Oct 2002 06:02:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9AD2MF08500; Thu, 10 Oct 2002 16:02:22 +0300 Date: Thu, 10 Oct 2002 16:02:21 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection 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 Wed, 9 Oct 2002, Erik Nordmark wrote: > > > The thing is, it seems like this (IMO relatively complex) iterative > > comparison algorithm must be run for every outbound packet (one might be > > able to optimize a bit with connection-oriented protocols). > > I think connection oriented protocols effectively require that > the source address (or addresses in the case of SCTP) be selected > when the connection is created. Thus trying to do this for every packet > would be the wrong thing in that case. Agreed. [...] > > An alternative seems to be to implement some form of (unspecified -- > > caching is only discussed in the context of dst address selection) > > optimizations. One example of optimization could be putting the > > to-be-used source address in the routing table, and refresh it always when > > rtable or any address of the node changes or changes state > > (deprecated/preferred, home address etc.), but these might have their own > > problems. > > > > My worry is, is it useful to specify a mechanism for selection default > > addresses that can't really be used without critical optimizations? > > I'm not worried about this. We have exactly the same issue for routing table > lookup in hosts and routers; there is no specification that states how > to implement caching schemes. We haven't really specified the source address selection like this for IPv4 either, I believe. Have I missed something? Routing table lookup is very simple compared to this I think. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 06:29:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ADTT29018258; Thu, 10 Oct 2002 06:29:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ADTT9D018257; Thu, 10 Oct 2002 06:29:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ADTQ29018250 for ; Thu, 10 Oct 2002 06:29:26 -0700 (PDT) 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 g9ADTTPG017075 for ; Thu, 10 Oct 2002 06:29:31 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22848 for ; Thu, 10 Oct 2002 07:29:24 -0600 (MDT) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9ADTCiZ027278 for ; Thu, 10 Oct 2002 09:29:12 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 09:29:21 -0400 Message-ID: <3DA58164.2080709@nc.rr.com> Date: Thu, 10 Oct 2002 09:32:20 -0400 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Wed, 9 Oct 2002, Erik Nordmark wrote: [snip] >>I'm not worried about this. We have exactly the same issue for routing table >>lookup in hosts and routers; there is no specification that states how >>to implement caching schemes. > > > We haven't really specified the source address selection like this for > IPv4 either, I believe. Have I missed something? > > Routing table lookup is very simple compared to this I think. Have you looked at the routing/forwarding sections of the scoped addressing architecture? It used to be simple. 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 Oct 10 07:15:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AEFh29018517; Thu, 10 Oct 2002 07:15:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AEFhoD018516; Thu, 10 Oct 2002 07:15:43 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AEFd29018509 for ; Thu, 10 Oct 2002 07:15:40 -0700 (PDT) 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 g9AEFZA06088; Thu, 10 Oct 2002 16:15:36 +0200 (MEST) Date: Thu, 10 Oct 2002 16:12:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Implementation worries about default address selection 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 > We haven't really specified the source address selection like this for > IPv4 either, I believe. Have I missed something? That wasn't what I said. I said that IETF specifications don't go into details on how to cache things, whether it is for "routing" or "source address selection". I suspect IPv4 implementations which allow more than one IP address per interface have some mechanism by which the source IP address is selected, since it can't just be the single IP address assigned to the outgoing interface. > Routing table lookup is very simple compared to this I think. Conceptually simple, yes. Making it perform, combining the routing table with the arp/nd cache for performance, etc makes it more complex. Source address selection is also conceptually simple. And making it perform well makes life more complex. 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 Oct 10 08:21:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AFLW29018943; Thu, 10 Oct 2002 08:21:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AFLWFh018942; Thu, 10 Oct 2002 08:21:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AFLS29018935 for ; Thu, 10 Oct 2002 08:21:28 -0700 (PDT) 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 g9AFLYPG005497 for ; Thu, 10 Oct 2002 08:21:34 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17705 for ; Thu, 10 Oct 2002 08:21:28 -0700 (PDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9AFKdsn026792; Thu, 10 Oct 2002 11:20:40 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA04301; Thu, 10 Oct 2002 11:21:08 -0400 (EDT) Date: Thu, 10 Oct 2002 11:20:35 -0400 To: Iljitsch van Beijnum , Michel Py Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, sommerfeld@east.sun.com, Margaret Wasserman Subject: Re: multihomed host Message-ID: <20021010152035.GB682@catfish> References: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021009232056.GN2310@catfish> <20021010084219.O85622-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021010084219.O85622-100000@sequoia.muada.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 79 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Iljitsch for detailed answer and Michel for the pointer. Actually, I'm working in the PANA WG and viewing this kind of multihomed host scenario from network access authentication perspective, and wondering whether the PANA WG needs to consider this scenario for now. (My impression is that there is a lot of work to consider before considering network access authentication) Yoshihiro Ohba On Thu, Oct 10, 2002 at 09:02:34AM +0200, Iljitsch van Beijnum wrote: > On Wed, 9 Oct 2002, Yoshihiro Ohba wrote: > > > > This is possible as of today; a host that has multiple PA addresses is > > > certainly considered a multihomed host. However, this alone is not a > > > multihoming solution. > > > What additional things need to be considered for this usage to become > > a multihoming solution? > > A good multihoming solution keeps working if there are failures. So the > applications must be smart enough to try all the addresses rather than > just one. Telnet and FTP do this, WWW clients typically don't. > Unfortunately, this must be done at the remote end and not on the > multi(homed|addressed) host itself. > > When there is a session, and the path over one ISP becomes unavailable, > the multihomed host must switch to the path over the other ISP. There are > many problems with this. First of all, the failure must be detected. Then > the host can reroute outgoing packets. But if the host still uses the same > source address (from the address space from the failed ISP), it is likely > the packets won't be accepted by the alternate ISP because the source > addresses are "spoofed". And even if they are, the communications partner > keeps sending packets back to th source address tied to the first ISP, > which isn't reachable any more. > > One solution for the address problem would be the adoption of new or > improved transport protocols that can handle this. There have been > experiments with modifications to TCP to support this, and the new SCTP > protocol can also handle this. However, modifying all transport protocols > might be problematic. > > Another solution is tunnelling/aliasing the packet to hide the original > address while the packet is rerouted over the alternative path. The > destination host or a box very close to the destination host strips of the > tunnel header or replaces the original address so TCP and other transport > protocols don't see the change in address. > > Some of us are working on this stuff on a non-IETF mailinglist. The latest > idea is to come up with a common tunnelling/aliasing framework so > different solutions in this area may interoperate. > > On Wed, Oct 09, 2002 at 11:11:09PM -0700, Michel Py wrote: > >>> Yoshihiro Ohba wrote: > >>> There may be some scenario in which a single-interface > >>> host is connected to multiple ISPs on the same link, which > >>> seems to be not covered in the usual definition for > >>> "multihomed host". I don't know what to call the model, > >>> but is such a model already common? Or is there any > >>> ongoing work on this model? > > >> Michel Py wrote: > >> This is possible as of today; a host that has multiple PA > >> addresses is certainly considered a multihomed host. > >> However, this alone is not a multihoming solution. > > > What additional things need to be considered for this > > usage to become a multihoming solution? > > There is no simple answer to this question. Here is one approach: > http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt > > 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 Oct 10 08:32:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AFW029019049; Thu, 10 Oct 2002 08:32:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AFVxlS019048; Thu, 10 Oct 2002 08:31:59 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AFVu29019041 for ; Thu, 10 Oct 2002 08:31:56 -0700 (PDT) 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 g9AFW1Mq014449 for ; Thu, 10 Oct 2002 08:32:01 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12771 for ; Thu, 10 Oct 2002 09:31:55 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id g9AFVvlw005153; Fri, 11 Oct 2002 00:31:57 +0900 Date: Fri, 11 Oct 2002 00:31:57 +0900 (JST) Message-Id: <20021011.003157.67016680.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just one comment. In article (at Sun, 6 Oct 2002 12:20:16 +0300 (EEST)), Pekka Savola says: > 1. another issue struct me while re-reading: the draft discusses > source/destination address selection separately: with S, select D from > D_1, D_2, ..., D_n, or with D, select S from S_1, S_2, ..., S_n. If I > understood correctly a fairly common case of S_1, S_2, ..., S_n *AND* D_1, > D_1, ..., D_n was not elaborated more (a brief mention in section 2?). D then S. |5. Source Address Selection | | The source address selection algorithm produces as output a single | source address for use with a given destination address. This -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 09:44:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AGiB29019326; Thu, 10 Oct 2002 09:44:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AGiBAF019325; Thu, 10 Oct 2002 09:44:11 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AGi829019318 for ; Thu, 10 Oct 2002 09:44:08 -0700 (PDT) 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 g9AGiDMq002182 for ; Thu, 10 Oct 2002 09:44:13 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09270 for ; Thu, 10 Oct 2002 10:44:08 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 10 Oct 2002 09:44:08 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 10 Oct 2002 09:44:08 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 10 Oct 2002 09:44:07 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 10 Oct 2002 09:44:07 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Thu, 10 Oct 2002 09:44:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Date: Thu, 10 Oct 2002 09:44:06 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1087450CE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt thread-index: AcJwRDZOAIRwIm/yT1CS5DmbPcJDRgAN6y8Q From: "Dave Thaler" To: "Brian Haberman" Cc: X-OriginalArrivalTime: 10 Oct 2002 16:44:06.0779 (UTC) FILETIME=[3FC2ECB0:01C2707C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9AGi829019319 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > >>From: Brian Haberman [mailto:bkhabs@nc.rr.com] > > > >> > > > >>>>The more I think about it, the more I realize that "automagically" > > > >>>>creating the subnet-local scope zone id isn't going to work. > > > >>>>Especially with multiple prefixes per interface. > > > >>> > > > > > > > > Why not? Can you elaborate? > > > > Shouldn't it always be true that if any two interfaces have the > > > > same (non-link-local) subnet prefix, then their subnet-local > > > > zone id MUST be the same? > > > > > > What happens to the zone ids when: > > > > > > 1. Interface 1 has prefix1 and prefix2 > > > 2. Interface 2 has prefix1 and prefix3 > > > 3. Interface 3 has prefix2 and prefix4 > > > > According to the default rule, all three are in the > > same subnet-local zone. You've just chosen for some > > reason not to advertise some prefixes on some links. > > Personally, I'd put this in the category of "don't do that", > > just like I wouldn't recommend using using different subnet > > ids for different prefixes on the same link. > > Why are some prefixes not advertised? Apparently because some admin configured it that way for some unknown (to me) reason. It's definitely not a zeroconf box in that configuration. > What happens if prefix3 is FE80:1:2:3::/64 and Interfaces 2&3 have > different site-local zone ids? Then you'd be in violation of the scoped addr architecture doc, since you're sharing the same global prefix (prefix2) across two site zones. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 10:31:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AHVQ29019773; Thu, 10 Oct 2002 10:31:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AHVQu6019772; Thu, 10 Oct 2002 10:31:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AHVN29019765 for ; Thu, 10 Oct 2002 10:31:23 -0700 (PDT) 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 g9AHVSPG009248 for ; Thu, 10 Oct 2002 10:31:28 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20484 for ; Thu, 10 Oct 2002 11:31:20 -0600 (MDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g9AHV4406213 for ; Thu, 10 Oct 2002 13:31:04 -0400 Date: Thu, 10 Oct 2002 13:31:04 -0400 (EDT) From: Joe Baptista To: Subject: IPv6 and child pornographers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The subject line says it all - IPv6 is a great protocol for free speech and other sorted activities. This is my last article on IPv6 - my next article will examine the costs associated with infrastructure. ---------- Forwarded message ---------- http://www.circleid.com/articles/2543.asp IPv6: In Search Of Internet Security October 9, 2002 By Joe Baptista My recent articles on IPv6 published this past September 12 and 25 have left many users with the impression that IPv6 (Internet Protocol version 6) is secure. This is a false assumption. Internet security is more an act of faith in a complex science draped in a religious mystery - in other words non-existent. In my opinion, Internet security has never existed. Any protocol can be violated. IPv6 has the power to make users' communication more secure during transmission. It also can be a security nightmare. So be warned, users of IPv6 - it will bypass your firewall settings but it will give your users enhanced privacy. But the experts are working on it. To understand Internet security it's always a good idea to go back in history. The Internet was a military sponsored communication project developed under DARPA (The Defense Advanced Research Projects Agency). The idea at the time was to distribute computer resources by decentralizing control and increasing redundancy on United States military and government networks. The goal was to prevent a first strike from taking out computational and communication facilities essential to operations. If the red menace (Soviet Union) bombed a computer facility in Kansas the network would route around the damage and survive. DARPA planners unfortunately were short sighted and did not anticipate the technology would become an international standard for communications. The community of users and networks connected to DARPA were small and trusted so security concerns were a low priority. The end result was the deployment of insecure protocols that have kept many security experts gainfully employed. Even secure protocols are hacked. Today there are millions of compromised computer systems busy trying to hack other computers. And many of those busy hacking computers may no longer be under the control of the original script kiddy hacker who launched them. In fact I suspect many such computers are operating independently of a human operator. IPv6 does fix a lot of the privacy issues and has some added security features that make it a better transport. Keith Moore, a researcher with the computer science department at the University of Tennessee, points out that "security is not an IPv6 issue any more than it is an IPv4 issue - probably slightly less." Moore, a former applications area director to the Internet Engineering Steering Group, points out that users of IPv6 will have an added advantage over IPv4. IPv6 transports traffic using the IPsec security protocol. IPv4 connections move traffic around in the clear (plain text). It is up to the user to ensure traffic is encrypted. Sniffer programs at various Internet exchange points can easily intercept most user web and email traffic. Cable users sometimes install sniffer programs to monitor and record IPv4 transmissions. In most cases they don't have the means to decrypt security protocols and they do it mostly for the fun and entertainment value. So don't panic, your credit card is still confidential provided you used it over a secure web session. However don't expect to send your credit card data to Uncle Steve via email. If you have however emailed confidential information to someone chances are your message was transported as plain text and can be subject to interception. The industry would agree that IPv4 is a brain dead protocol and those predicting it's death have good reasons for their position. Government programs like carnivore depended on IPv4 vulnerabilities to be successful. Carnivore is a tool that has revitalized worldwide respect for the FBI in the intelligence community. The program intercepts and analyzes Internet traffic and is classified by the FBI as a diagnostic tool. Carnivore is also a motivating factor in the transition to IPv6 by American, European and Japanese governments. Governments understand their vulnerabilities under IPv4; their intelligence departments have diagnostic tools too. IPsec makes IPv6 less prone to man in the middle interception or attacks. User data under IPv6 is encrypted across the transmission end points. Sure the intelligence establishment has the means to break encrypted protocols but that's an expensive affair. Carnivore has not been effective in catching terrorists who communicate using encrypted channels. But it's been very effective in catching child pornographers that have yet to discover the privacy features available to them under IPv6. It is easy to envision that Carnivore will become a useless diagnostic tool under the new protocol. But in many cases IPv6 systems can be less secure. Your firewall may prevent access to your Microsoft shares under IPv4 but they will be wide open to IPv6 users. Iljitsch van Beijnum a freelance network specialist and author of "Border Gateway Protocol" the network routing howto manual has some concerns when it comes to security. Beijnum warns that many Unix boxes are heavily firewalled in IPv4 but not in IPv6. "If you happen to be on their local link (hello wireless)" said Beijnum "you can circumvent the IPv4 access restrictions for services that are v6-enabled". He explains that in most cases users don't even know the box is doing IPv6. User should secure their systems prior to turning on or installing IPv6 services. On the brighter side of the IPv6 universe, workstations will be easier to hide from the evil hacker. An IPv6 allocation contains addresses in the trillions. This means old hacker tricks like scanning a network will become less affective. When your workstation uses one address out of trillions it makes targeted probes a less likely menace to an individual or organization. IPv6 workstations, which use privacy extensions for stateless address autoconfiguration, will certainly benefit. However systems which are using old IPv6 protocol stacks that do not incorporate the privacy extensions developed by Thomas Narten of IBM and Track Draves at Microsoft Research will most likely be targets for tracking. Old IPv6 protocols may publish your workstation or laptops unique electronic fingerprint. Make sure your IPv6 system is RFC 3041 compliant or else your privacy may be at risk. Conclusion: IPv6 is a protocol that delivers on user privacy. If you want your enterprise servers to provide privacy to your facilities then IPv6 is the way to go. If you want security the best advise I can give any Internet user is that you pray and have faith or disconnect your computer when not in use. Enterprises, non-profit organizations, governments and small business that have a need for privacy should consider a transition to IPv6. But make sure you get a security check done on your systems. Those interested in connecting to the IPv6 network should visit the IPv6 forum and I maintain a [28]list of providers. Enjoy! -- Joe Baptista is a managing director of The dot.GOD Registry, Limited a not for profit provider of network infrastructure, and domain names inclusive namespace. Joe is also involved in Internet governance as a member of the General Assembly of the Domain Name Supporting Organization (DNSO) of The Internet Corporation for Assigned Names and Numbers (ICANN). Joe has been interviewed by the leading Canadian newspapers, radio and television on various Internet issues. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 11:26:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AIQH29020161; Thu, 10 Oct 2002 11:26:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AIQHJC020160; Thu, 10 Oct 2002 11:26:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AIQE29020153 for ; Thu, 10 Oct 2002 11:26:14 -0700 (PDT) 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 g9AIQJPG024599 for ; Thu, 10 Oct 2002 11:26:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27122 for ; Thu, 10 Oct 2002 12:26:08 -0600 (MDT) 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 g9AIPTM23391; Fri, 11 Oct 2002 01:25:30 +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 g9AIP8U09074; Fri, 11 Oct 2002 01:25:10 +0700 (ICT) From: Robert Elz To: "Dave Thaler" cc: "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Oct 2002 01:25:08 +0700 Message-ID: <9072.1034274308@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 9 Oct 2002 12:18:09 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> It should be fairly obvious by now that I haven't yet read the scoping-arch doc ... Normally I wouldn't comment about something I haven't read, my excuse is that that's not what I thought I was doing here, I though I was commenting on the addr-arch-v3 doc, which is the one in the subject... That so much of this is turning on points related to the scoping-arch doc, which isn't even a PS yet, suggests to me that: | > > So, this would be consistent with the suggestion that we | > > change the Addr Arch document to list subnet-local and larger | > > scopes as administratively defined (instead of just admin-local | > > and higher)? | > | > Yes. Given the issues with magically setting the subnet-local | > zone id when multiple prefixes are enabled on an interface I | > would agree with that change. | | I would disagree with that change. So would I. The change I would make is to delete all references of subnet-local from the addr-arch doc, and simply leave those values as "to be defined" and then define them in the scoping-arch doc. Sticking new stuff in docs, as they're in the process of going from PS to DS is generally not proper, and while just defining a new number is probably not going to be the kind of thing that would cause a problem, doing so when there is no existing meaning for that number will just lead to potential confusion. That is, what happens if addr-arch is published as a DS, and even gets to full std, with "subnet-local scope" in it, but the IETF never finishes defining the subnet local stuff, and it eventually all just vanishes from sight? In 20 years, people will be wondering what this strange definition of a subnet local scope, that has no meaning is all about. Best is to remove it from the current doc, and place the definition where it really belongs. Let's not have the addr arch doc anticipate what might come in the future, | The zero-config counter argument is a box that is labeled as | having its default configuration be that interfaces are on the | same subnet different but different links (e.g. guaranteed | to be different because they're different media, like an | 802.11 access point with a wired Ethernet link). That's not a good example. Remember the "link" we're talking about here isn't a physical link - that idea vanished when repeaters were first invented (which was just about the same time as ethernet). A link for our purposes is the place where broadcast/multicast packets will go, and that can certainly cross a wired/wireless ethernet boundary. Not that it always will, but it certainly can, so "guaranteed to be different" isn't the case there. A better example would be a subnet made up of an ATM link and an ethernet link (where the ATM is not running LANE). Or to be more perverse perhaps, an X.25 link and an ethernet link. There, the link level address formats differ, so they cannot possibly be same link. (There are plenty of other examples). I'm not sure I'd expect to see many zeoconf boxes that fit this "guaranteed to be different" kind of model ever actually appear. So I'm not sure I'd be treating arguments about what they might do very seriously. I'm also not sure I really like the restrictions that seem to be being proposed for subnet-local - they seem to blow away some of the expectations I'd had for where and why I'd actually want to use multi-link subnets (which certainly isn't as some kind of alternative to bridging wireless and wired lans). But I will wait until after I have actually read that draft before I make comments about that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 14:13:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALDI29020810; Thu, 10 Oct 2002 14:13:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ALDIRS020809; Thu, 10 Oct 2002 14:13:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALDE29020802 for ; Thu, 10 Oct 2002 14:13:15 -0700 (PDT) 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 g9ALDJPG009481 for ; Thu, 10 Oct 2002 14:13:20 -0700 (PDT) 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 PAA07460 for ; Thu, 10 Oct 2002 15:13:14 -0600 (MDT) Received: from heavygear ([147.11.233.15]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id OAA13610 for ; Thu, 10 Oct 2002 14:12:23 -0700 (PDT) From: "Qing Li" To: Subject: question on next-hop determination Date: Thu, 10 Oct 2002 14:12:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC2461, section 5.2, paragraph 2, the last sentence is "If the Default Router List is empty, the sender assumes that the destination is on-link." Why should the destination be considered on-link ?? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 14:22:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALMk29020869; Thu, 10 Oct 2002 14:22:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ALMjIL020868; Thu, 10 Oct 2002 14:22:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALMg29020861 for ; Thu, 10 Oct 2002 14:22:42 -0700 (PDT) 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 g9ALMlPG011941 for ; Thu, 10 Oct 2002 14:22:47 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12447 for ; Thu, 10 Oct 2002 15:22:42 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA02211 for ; Thu, 10 Oct 2002 14:22:41 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA11842 for ; Thu, 10 Oct 2002 14:19:28 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2656.59) id <44RFP230>; Thu, 10 Oct 2002 16:21:51 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Qing Li'" , ipng@sunroof.eng.sun.com Subject: RE: question on next-hop determination Date: Thu, 10 Oct 2002 16:21:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Probably because there is no way to get off the link. Cyndi -----Original Message----- From: Qing Li [mailto:Qing.Li@windriver.com] Sent: Thursday, October 10, 2002 2:12 PM To: ipng@sunroof.eng.sun.com Subject: question on next-hop determination In RFC2461, section 5.2, paragraph 2, the last sentence is "If the Default Router List is empty, the sender assumes that the destination is on-link." Why should the destination be considered on-link ?? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 14:39:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALdX29021018; Thu, 10 Oct 2002 14:39:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ALdXpV021017; Thu, 10 Oct 2002 14:39:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ALdT29021010 for ; Thu, 10 Oct 2002 14:39:30 -0700 (PDT) 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 g9ALdZPG016257 for ; Thu, 10 Oct 2002 14:39:35 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07400 for ; Thu, 10 Oct 2002 14:39:29 -0700 (PDT) Received: from heavygear ([147.11.233.15]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id OAA04385; Thu, 10 Oct 2002 14:38:36 -0700 (PDT) From: "Qing Li" To: "Jung Cyndi-ACJ099" , Subject: RE: question on next-hop determination Date: Thu, 10 Oct 2002 14:38:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Probably because there is no way to get off the link. > I am not sure I understand what you mean. Host A and Host B have different global routing prefixes, and for whatever reason Host A has an empty default router list. Why should Host A consider Host B on-link ? It would be wrong for Host A to send neighbor solication for Host B, no ? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 15:39:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AMdg29021387; Thu, 10 Oct 2002 15:39:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9AMdg5s021386; Thu, 10 Oct 2002 15:39:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9AMdb29021379 for ; Thu, 10 Oct 2002 15:39:37 -0700 (PDT) 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 g9AMdhMq011501 for ; Thu, 10 Oct 2002 15:39:43 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29647 for ; Thu, 10 Oct 2002 16:39:37 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9AMdFKV012071; Fri, 11 Oct 2002 00:39:15 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <44LQ3NKS>; Fri, 11 Oct 2002 00:39:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B2D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'William Waites'" , Bill Sommerfeld Cc: Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: RE: multihomed host Date: Fri, 11 Oct 2002 00:39:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>> "Bill" == Bill Sommerfeld writes: > > Bill> For what it's worth, I've occasionally heard > the term used > Bill> in an application-layer context to refer to > hosts having > Bill> multiple IP addresses rather than/in addition > to multiple > Bill> interfaces. > > This just looks like the degenerate case -- multiple > addresses, > multiple interfaces, except that each of the multiple > interfaces > happen to be the same. It seems to me that the network > layer code > should treat both cases identically. Does this make sense? => I don't think so. There is a difference in existing standards (2461) and implementations between the 2 cases. A multiaddressed node with a single interface assumes that any address can be used as a source address with any default router. This is clearly not a good assumption for multi-interfaced (multihomed) nodes Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 18:12:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1Ca29021877; Thu, 10 Oct 2002 18:12:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B1Ca6C021876; Thu, 10 Oct 2002 18:12:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1CX29021869 for ; Thu, 10 Oct 2002 18:12:33 -0700 (PDT) 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 g9B1CcPG006988 for ; Thu, 10 Oct 2002 18:12:38 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02269 for ; Thu, 10 Oct 2002 18:12:32 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9B1AZ804398; Thu, 10 Oct 2002 21:10:39 -0400 Message-Id: <200210110110.g9B1AZ804398@cichlid.adsl.duke.edu> To: Brett Pentland cc: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 In-Reply-To: Message from Brett Pentland of "Thu, 10 Oct 2002 15:25:05 +1000." <3DA50F31.820D12D7@monash.edu> Date: Thu, 10 Oct 2002 21:10:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Certainly obtaining router information is only one part of the problem > and as you pointed out, the one second delay for DAD is a greater > problem. From a mobile IPv6 point of view, there is also the problem of > completing binding updates with home agents or correspondant nodes that > are a long way away. However, there has been some discussion about > "optimistic DAD" or even doing away with DAD for certain types of > addresses (though concensus on that seems a way off...) and heirachical > MIPv6 reduces the need to signal far away devices. I see sending fast > RAs as one piece in the puzzle. Seems to me then that this document is a bit narrowly scoped and may even miss the point. Don't we need to look at the overall problem and then see what can be done to address the overall problem adequately? In general, I don't know that its all that useful to focus on a narrow part of a bigger problem unless the bigger problem is sufficiently understood that the point solution is understood to be an important and useful component of it. How do we know that this change will make any significant difference in practice given the general problem? 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 Thu Oct 10 18:16:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1GC29021908; Thu, 10 Oct 2002 18:16:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B1GCUV021907; Thu, 10 Oct 2002 18:16:12 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1Fj29021897 for ; Thu, 10 Oct 2002 18:16:08 -0700 (PDT) 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 g9B1FoMq016753 for ; Thu, 10 Oct 2002 18:15:50 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18869 for ; Thu, 10 Oct 2002 19:15:44 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9B1Du204440; Thu, 10 Oct 2002 21:13:57 -0400 Message-Id: <200210110113.g9B1Du204440@cichlid.adsl.duke.edu> To: "Qing Li" cc: ipng@sunroof.eng.sun.com Subject: Re: question on next-hop determination In-Reply-To: Message from "Qing Li" of "Thu, 10 Oct 2002 14:12:12 PDT." Date: Thu, 10 Oct 2002 21:13:56 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In RFC2461, section 5.2, paragraph 2, the last > sentence is "If the Default Router List is empty, > the sender assumes that the destination is on-link." > Why should the destination be considered on-link ?? Its a last resort. I.e., assuming on-link may be a better as the final last step compared with just giving up. 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 Thu Oct 10 18:54:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1sM29022080; Thu, 10 Oct 2002 18:54:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B1sMSm022079; Thu, 10 Oct 2002 18:54:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B1sJ29022072 for ; Thu, 10 Oct 2002 18:54:19 -0700 (PDT) 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 g9B1sOPG013201 for ; Thu, 10 Oct 2002 18:54:24 -0700 (PDT) Received: from mail010.syd.optusnet.com.au (mail010.syd.optusnet.com.au [210.49.20.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29695 for ; Thu, 10 Oct 2002 19:54:17 -0600 (MDT) Received: from co3016429a (c17345.lowrp1.vic.optusnet.com.au [210.49.213.205]) by mail010.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g9B1sDF30526; Fri, 11 Oct 2002 11:54:13 +1000 Message-ID: <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> From: "Richard Nelson" To: "Thomas Narten" Cc: References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Fri, 11 Oct 2002 11:57:57 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Thomas Narten" > > Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router > delays a random amount of time between 0 and .5 seconds before > responding. So, on average, .25 seconds. That's not a terribly long > delay. What exactly is the application that can't deal with this kind > of a delay? Plenty, voice particularly, but it might also kill your TCP transfer. Also saying average .25 sec fudges the issue, 10% of the time it will be greater than .45 sec so users will normally see near the worst case some of the time. > > Then there is more to getting link connectivity than just finding a > router. You may have to generate an address, and then invoke DAD. But > DAD (on an Ethernet) requires a 1 second delay. That's a much bigger > factor than the RS delay. Is this not also an issue? I.e., what is so > critical about getting an immediate RS but that doesn't also have an > issue with some of the other ND/addrconf/DAD constants. Yep it is a big issue, but there are solutions to that as well. Will > addressing the RS delay alone *really* solve the problem here, and if > not, shouldn't we be thinking about the more general problem and > working on finding a solution that deals with all the potential delay > spots? Well the general solution is fast handovers and that is being worked on. But without fast handovers, if you use fast RAs and HMIP and get rid of DAD somehow, the MIPv6 handover can be a few 10s of milliseconds. If you have a fast L2 handover (A big if as it turns out) it is possible that MIPv6 handovers could be really useful even with real time traffic. Richard. > > 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 Thu Oct 10 19:06:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B26G29022149; Thu, 10 Oct 2002 19:06:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B26Gwd022148; Thu, 10 Oct 2002 19:06:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B26D29022141 for ; Thu, 10 Oct 2002 19:06:13 -0700 (PDT) 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 g9B26IPG014957 for ; Thu, 10 Oct 2002 19:06:18 -0700 (PDT) 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 UAA05458 for ; Thu, 10 Oct 2002 20:06:11 -0600 (MDT) Received: from heavygear ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id TAA13372; Thu, 10 Oct 2002 19:05:01 -0700 (PDT) From: "Qing Li" To: "Thomas Narten" Cc: Subject: RE: question on next-hop determination Date: Thu, 10 Oct 2002 19:04:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200210110113.g9B1Du204440@cichlid.adsl.duke.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > In RFC2461, section 5.2, paragraph 2, the last > > sentence is "If the Default Router List is empty, > > the sender assumes that the destination is on-link." > > > Why should the destination be considered on-link ?? > > Its a last resort. I.e., assuming on-link may be a better as the final > last step compared with just giving up. > I think the sending host should just drop the packet when the destination is not covered in its prefix list and there is no default route installed. Otherwise IMHO this last attempt would lead to erroneous packet generation, and allows misconfigured host or host running a buggy implementation to continue with bad behavior. Also the code put in to supporting this looks and feels like hacks. Could you please describe a scenario in which such a situation might occur, and it makes sense to make this final attempt ?? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 21:30:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B4U429022633; Thu, 10 Oct 2002 21:30:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B4U3Wc022632; Thu, 10 Oct 2002 21:30:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B4U029022625 for ; Thu, 10 Oct 2002 21:30:00 -0700 (PDT) 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 g9B4U5PG003904 for ; Thu, 10 Oct 2002 21:30:05 -0700 (PDT) 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 VAA25935 for ; Thu, 10 Oct 2002 21:30:00 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CFA6EB08; Fri, 11 Oct 2002 00:29:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Oct 2002 00:29:54 -0400 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: Implementation worries about default address selection Date: Fri, 11 Oct 2002 00:29:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D3475@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implementation worries about default address selection Thread-Index: AcJwXZ4pGP0qKf0NQEye7zR6l782NAAXJwUg From: "Bound, Jim" To: "Pekka Savola" , "Erik Nordmark" Cc: X-OriginalArrivalTime: 11 Oct 2002 04:29:54.0613 (UTC) FILETIME=[D9099650:01C270DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9B4U029022626 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Just as a comment. I am reading your many new drafts. They are very good reading too. But you seem to be wanting to standardize "implementation" practices often in your drafts and emails. In the IETF we do and should not standardize that which is implementation or usr configurable or usr database etc. Another example was a recent exchange between an AD and another member who is a routing vendor expert. The AD was asking some pretty basic questions about why a routinug table should or should not do something and that we may want to standardize it. My point of relaying this is that we need to build protocol standards our job is not to build standards for implementation. That being said. When you ask to build a standard for implementation I simply won't respond to so you won't hear from me and I am one of the implementors on this list for much of what you ask that could respond. If you want to discuss implementation we have IPv6 implementation lists that are not part of the IETF. regards, /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, October 10, 2002 9:02 AM > To: Erik Nordmark > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Implementation worries about default address selection > > > On Wed, 9 Oct 2002, Erik Nordmark wrote: > > > > > > The thing is, it seems like this (IMO relatively complex) > iterative > > > comparison algorithm must be run for every outbound > packet (one might be > > > able to optimize a bit with connection-oriented protocols). > > > > I think connection oriented protocols effectively require that > > the source address (or addresses in the case of SCTP) be selected > > when the connection is created. Thus trying to do this for > every packet > > would be the wrong thing in that case. > > Agreed. > > [...] > > > > An alternative seems to be to implement some form of > (unspecified -- > > > caching is only discussed in the context of dst address selection) > > > optimizations. One example of optimization could be putting the > > > to-be-used source address in the routing table, and > refresh it always when > > > rtable or any address of the node changes or changes state > > > (deprecated/preferred, home address etc.), but these > might have their own > > > problems. > > > > > > My worry is, is it useful to specify a mechanism for > selection default > > > addresses that can't really be used without critical > optimizations? > > > > I'm not worried about this. We have exactly the same issue > for routing table > > lookup in hosts and routers; there is no specification that > states how > > to implement caching schemes. > > We haven't really specified the source address selection like > this for > IPv4 either, I believe. Have I missed something? > > Routing table lookup is very simple compared to this I think. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 21:42:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B4g229022740; Thu, 10 Oct 2002 21:42:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B4g2Aa022739; Thu, 10 Oct 2002 21:42:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B4fx29022732 for ; Thu, 10 Oct 2002 21:41:59 -0700 (PDT) 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 g9B4g4PG005531 for ; Thu, 10 Oct 2002 21:42:04 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15234 for ; Thu, 10 Oct 2002 22:41:57 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KNJJ52UCRO94DZWG@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 11 Oct 2002 14:40:37 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 57A2412C074; Fri, 11 Oct 2002 14:40:30 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id E84B212C033; Fri, 11 Oct 2002 14:40:27 +1000 (EST) Date: Fri, 11 Oct 2002 14:40:27 +1000 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: Richard Nelson Cc: Thomas Narten , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DA6563B.9070605@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Richard & Thomas I'd just like to indicate that we have seen the delay for router advertisement to be a significant delay in MIPv6 handovers, since there is no DAD in the case where a mobile node moves back to a previously visited network. In this case, the RS/RA delay is the biggest factor in the L3 handover time (dwarfing signalling since we use HMIPv6). Even in the case of fast handovers for MIPv6, any delay before the receipt of an RA can cause performance degradation, because a node cannot determine if it is on the correct access network until it receives this advertisement (and thus cannot finalize its address acquisition and signalling). Each of the delays in the handover are discrete issues, related to the design of the original protocols (which are good, but not tuned for mobility). There may be an integrated solution, which gets around most of these issues, but there are also several simple modifications which I think should be considered to DAD and neighbour discovery (where the delays occur). Since they may be deployed without harm to other systems, nor complicated reliances on Link-layer technologies. I think that a co-ordinated approach to these issues is needed, rather than a single integrated solution. Greg Daley Richard Nelson wrote: > ----- Original Message ----- > From: "Thomas Narten" > >>Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router >>delays a random amount of time between 0 and .5 seconds before >>responding. So, on average, .25 seconds. That's not a terribly long >>delay. What exactly is the application that can't deal with this kind >>of a delay? > > > Plenty, voice particularly, but it might also kill your TCP transfer. Also > saying average .25 sec fudges the issue, 10% of the time it will be greater > than .45 sec so users will normally see near the worst case some of the > time. > >>Then there is more to getting link connectivity than just finding a >>router. You may have to generate an address, and then invoke DAD. But >>DAD (on an Ethernet) requires a 1 second delay. That's a much bigger >>factor than the RS delay. Is this not also an issue? I.e., what is so >>critical about getting an immediate RS but that doesn't also have an >>issue with some of the other ND/addrconf/DAD constants. > > > Yep it is a big issue, but there are solutions to that as well. > > Will > >>addressing the RS delay alone *really* solve the problem here, and if >>not, shouldn't we be thinking about the more general problem and >>working on finding a solution that deals with all the potential delay >>spots? > > > Well the general solution is fast handovers and that is being worked on. > But without fast handovers, if you use fast RAs and HMIP and get rid of DAD > somehow, the MIPv6 handover can be a few 10s of milliseconds. If you have a > fast L2 handover (A big if as it turns out) it is possible that MIPv6 > handovers could be really useful even with real time traffic. > > > Richard. > > >>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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 22:07:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B57629022922; Thu, 10 Oct 2002 22:07:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B576It022921; Thu, 10 Oct 2002 22:07:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B57329022914; Thu, 10 Oct 2002 22:07:03 -0700 (PDT) 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 g9B578PG008977; Thu, 10 Oct 2002 22:07:08 -0700 (PDT) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20250; Thu, 10 Oct 2002 22:06:57 -0700 (PDT) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id g9B52Xg6021736; Fri, 11 Oct 2002 10:32:36 +0530 Message-ID: <006101c270e4$4cd61c70$b202a8c0@iwave120> From: "Anurag Uxa" To: , "'Pekka Savola'" Cc: , References: <088601c26f50$0dfb8750$011aa8c0@eagleswings> Subject: Query about automatic tunneling and ND Date: Fri, 11 Oct 2002 10:38:44 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C27112.5F733150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C27112.5F733150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All I have few queries. I have gone through all drafts and RFC 3056,2893, But still i am not = able to under stand=20 HOST1 and HOST2 are in different networks and having IPv6=20 addresses HOST1 send one tunneled IPV4 packet to the HOST2 (Before sending the tunneled packet out, Will the=20 HOST1 send tunneled mulitcast NS to HOST2 ?). 1. PS:2893-If an implementation provides bidirectional configured tunnels = it MUST at least accept and respond to the probe packets used by = Neighbor Unreachability Detection [for ND all new drafts and rfc3056 is = reffering RFC2893. 2. [RFC2893] SHOULD also send NUD probe packets to detect when the = configured tunnel fails at which point the implementation can use an = alternate path to reach the destination. Please anybody can explain with examples then i will be very thank ful Anurag Uxa http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt has removed them for lack of ability to scale well.=20 Spend more time on RFC 3056,=20 http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-04.txt,=20 & = http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-08.txt ----- Original Message -----=20 From: "Tony Hain" To: "'Anurag Uxa'" ; "'Pekka Savola'" = Cc: ; Sent: Wednesday, October 09, 2002 10:25 AM Subject: RE: Query about automatic tunneling and ND > Anurag Uxa wrote: > > Dear Mr. Tony and all > >=20 > > I have two queries . Can you pls give me the details. and=20 > > tell me about some usefull document . > >=20 > > Questions: > > 1. > > HOST1 and HOST2 are in different networks and having IPv6=20 > > addresses HOST1 send one tunneled IPV4 packet > IPV6 UDP packet> to the HOST2 > > (Before sending the tunneled packet out, Will the=20 > > HOST1 send tunneled mulitcast NS to HOST2 ? > Confirmation>) >=20 > No, there is no need for NS because the necessary 'link' reachability > information is already imbedded in the IPv6 address. >=20 > >=20 > > 2. > > Is Automatic tunnels always unidirectional or only for=20 > > following condition [Neighbor Discovery and Stateless Address=20 > > Autoconfiguration] ? >=20 > Yes they are always unidirectional.=20 >=20 > >=20 > > P.S: RFC-2893 > > Automatic tunnels and unidirectional configured tunnels are=20 > > considered to be unidirectional. Thus the only aspects of Neighbor > >=20 > > Discovery [7] and Stateless Address Autoconfiguration [5]=20 > > that apply to these tunnels is the formation of the=20 > > link-local address. >=20 > Don't spend too much time on 2893 type automatic tunnels. The > replacement > >=20 >=20 > Tony >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Thanks > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > IF U FIND SOME ONE WITHOUT A SMILE,GIVE ONE OF YOUR'S > >=20 > > Anurag Uxa > > IWave Embedded systems > > Bangalore > > ph.6786243/5 extn :210 > >=20 > >=20 > >=20 > > DISCLAIMER: > >=20 > > This e-mail and any attachment (s) is for authorised use by=20 > > the intended recipient (s) only. It may contain proprietary=20 > > material, confidential information and/or be subject to the=20 > > legal privilege of iWave Systems Technologies Private=20 > > Limited. If you have received this message in error, please=20 > > notify the originator immediately. If you are not the=20 > > intended recipient, you are notified that you are strictly=20 > > prohibited from retaining, using, copying, alerting or=20 > > disclosing the content of this message. Thank you for your=20 > > co-operation.=20 > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_005E_01C27112.5F733150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
I have few queries.
I have gone through all drafts and RFC = 3056,2893,=20 But still i am not able to under stand
 
HOST1 and HOST2 are in different = networks and=20 having IPv6 
addresses HOST1 send one tunneled IPV4 packet=20 <Encapsulated  IPV6 UDP packet> to the=20 HOST2
          &nbs= p; =20 (Before sending the tunneled packet out, Will the 
HOST1 send = tunneled=20 mulitcast NS to HOST2 ?<For=20 Reachability Confirmation>).

1.
PS:2893-If=20 an implementation provides bidirectional configured tunnels it MUST at = least=20 accept and respond to the probe packets used by Neighbor Unreachability=20 Detection [for ND all new drafts and rfc3056 is reffering=20 RFC2893.
2.
[RFC2893] SHOULD also send NUD probe packets to = detect when=20 the configured tunnel fails at which point the implementation can use an = alternate path to reach the destination.
 
 
 
 
Please anybody can explain with examples then i = will be very=20 thank ful
 
Anurag Uxa
 
 
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-0= 0.txt
 has removed them for lack of ability to = scale=20 well. 
Spend more time on RFC 3056, 
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-04= .txt, 
& http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-= 08.txt
 
----- Original Message -----
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Anurag Uxa'" <anuraguxa@iwavesystems.com>;=20 "'Pekka Savola'" <pekkas@netcore.fi>
Cc: <ngtrans@sunroof.eng.sun.com>;=20 <ipng@sunroof.eng.sun.com>
Sent: Wednesday, October 09, 2002 10:25 = AM
Subject: RE: Query about automatic = tunneling and=20 ND

> Anurag Uxa wrote:
> > Dear Mr. Tony and = all
> >=20
> > I have two queries . Can you pls give me the details. and =
>=20 > tell me about some usefull document .
> >
> >=20 Questions:
> > 1.
> > HOST1 and HOST2 are in different = networks and having IPv6
> > addresses HOST1 send one tunneled = IPV4=20 packet <Encapsulated
> > IPV6 UDP packet> to the = HOST2
>=20 >           &nb= sp;=20 (Before sending the tunneled packet out, Will the
> > HOST1 = send=20 tunneled mulitcast NS to HOST2 ?<For Reachability
> >=20 Confirmation>)
>
> No, there is no need for NS because = the=20 necessary 'link' reachability
> information is already imbedded in = the=20 IPv6 address.
>
> >
> > 2.
> > Is = Automatic=20 tunnels always unidirectional or only for
> > following = condition=20 [Neighbor Discovery and Stateless Address
> > = Autoconfiguration]=20 ?
>
> Yes they are always unidirectional.
>
> = >=20
> > P.S: RFC-2893
> > Automatic tunnels and = unidirectional=20 configured tunnels are
> > considered to be unidirectional. = Thus the=20 only aspects of Neighbor
> >
> > Discovery [7] and = Stateless=20 Address Autoconfiguration [5]
> > that apply to these tunnels = is the=20 formation of the
> > link-local address.
>
> = Don't spend=20 too much time on 2893 type automatic tunnels. The
> = replacement
>=20 >
>
> Tony
>
> >
> >
> = >=20
> >
> >
> > Thanks
> >=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > IF U FIND = SOME=20 ONE WITHOUT A SMILE,GIVE ONE OF YOUR'S
> >
> > Anurag = Uxa
> > IWave Embedded systems
> > Bangalore
> = >=20 ph.6786243/5 extn :210
> >
> >
> >
> = >=20 DISCLAIMER:
> >
> > This e-mail and any attachment = (s) is for=20 authorised use by
> > the intended recipient (s) only. It may = contain=20 proprietary
> > material, confidential information and/or be = subject=20 to the
> > legal privilege of iWave Systems Technologies = Private=20
> > Limited. If you have received this message in error, = please=20
> > notify the originator immediately. If you are not the =
>=20 > intended recipient, you are notified that you are strictly
> = >=20 prohibited from retaining, using, copying, alerting or
> > = disclosing=20 the content of this message. Thank you for your
> > = co-operation.=20
> >=20 --------------------------------------------------------------------
&= gt;=20 > IETF IPng Working Group Mailing List
> > IPng Home=20 Page:           &n= bsp;         =20 http://playground.sun.com/ipng
>=20 > FTP=20 archive:           = ;          =20 ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
>=20 >=20 --------------------------------------------------------------------
&= gt;=20 >
>
>
>=20 --------------------------------------------------------------------
&= gt;=20 IETF IPng Working Group Mailing List
> IPng Home=20 Page:           &n= bsp;         =20 http://playground.sun.com/ipng
>=20 FTP=20 archive:           = ;          =20 ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
>=20 --------------------------------------------------------------------
&= gt;=20

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_005E_01C27112.5F733150-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 22:29:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B5TF29023068; Thu, 10 Oct 2002 22:29:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B5TFsk023067; Thu, 10 Oct 2002 22:29:15 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B5TC29023060; Thu, 10 Oct 2002 22:29:12 -0700 (PDT) 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 g9B5THMq025715; Thu, 10 Oct 2002 22:29:17 -0700 (PDT) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02038; Thu, 10 Oct 2002 23:29:08 -0600 (MDT) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id g9B5PWg6021849; Fri, 11 Oct 2002 10:55:32 +0530 Message-ID: <007e01c270e7$7f4aa5b0$b202a8c0@iwave120> From: "Anurag Uxa" To: , Subject: IPv6 native address Date: Fri, 11 Oct 2002 11:01:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C27115.958C0A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C27115.958C0A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All Can any body help me ??? Yesterday i was seeing one PDF file. It was talking about Ipv6 native = address. they had given prefix length 48 bits. given example was 1080:0:FF:0:8:856:200c:5432/48. (as per RFC saysThe remainder of the IPv6 address space. An IPv6 = address that bears a prefix other than 0:0:0:0:0:0.)means prefix length = should be 96 bits.=20 pls give me correct format of IPv6 native address. Thanks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IF U FIND SOME ONE WITHOUT A SMILE,GIVE ONE OF YOUR'S Anurag Uxa IWave Embedded systems Bangalore ph.6786243/5 extn :210 DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_007B_01C27115.958C0A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
Can any body help me ???
 
Yesterday i was seeing one PDF = file. It was=20 talking about Ipv6 native address. they had given prefix = length 48=20 bits.
given example was=20 1080:0:FF:0:8:856:200c:5432/48.
 
(as per RFC = saysThe remainder=20 of the IPv6 address space.  An IPv6 address that bears a prefix = other than=20 0:0:0:0:0:0.)means prefix length should be 96=20 bits. 
pls give me correct = format of IPv6=20 native address.
Thanks
 
 
 
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IF U FIND SOME ONE WITHOUT A SMILE,GIVE = ONE OF=20 YOUR'S
 
Anurag Uxa
IWave Embedded=20 systems
Bangalore
ph.6786243/5 extn = :210

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_007B_01C27115.958C0A70-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 10 23:24:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6OJ29023257; Thu, 10 Oct 2002 23:24:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B6OJfb023256; Thu, 10 Oct 2002 23:24:19 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6OF29023249 for ; Thu, 10 Oct 2002 23:24:16 -0700 (PDT) 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 g9B6OKMq002008 for ; Thu, 10 Oct 2002 23:24:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27496 for ; Fri, 11 Oct 2002 00:24:14 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9B6O4e17387; Fri, 11 Oct 2002 09:24:10 +0300 Date: Fri, 11 Oct 2002 09:24:04 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection In-Reply-To: <20021011.003157.67016680.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Sun, 6 Oct 2002 12:20:16 +0300 (EEST)), Pekka Savola says: > > > 1. another issue struct me while re-reading: the draft discusses > > source/destination address selection separately: with S, select D from > > D_1, D_2, ..., D_n, or with D, select S from S_1, S_2, ..., S_n. If I > > understood correctly a fairly common case of S_1, S_2, ..., S_n *AND* D_1, > > D_1, ..., D_n was not elaborated more (a brief mention in section 2?). > > D then S. > > |5. Source Address Selection > | > | The source address selection algorithm produces as output a single > | source address for use with a given destination address. This Yes, that is clear (the algorithm must have only one destination), but the question arises how much this makes sense (as the destination address may already have been selected using some arbitrary source address for comparing against the destination address). The extra steps may not harm of course (extra work..). One possibly interesting scenario could be when source or destination address selection has been upgraded to honor this but the other isn't. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 23:35:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6Zg29023332; Thu, 10 Oct 2002 23:35:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B6ZggU023331; Thu, 10 Oct 2002 23:35:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6Zd29023324 for ; Thu, 10 Oct 2002 23:35:39 -0700 (PDT) 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 g9B6ZiPG018973 for ; Thu, 10 Oct 2002 23:35:45 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA04830 for ; Fri, 11 Oct 2002 00:35:37 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9B6ZUS17471; Fri, 11 Oct 2002 09:35:30 +0300 Date: Fri, 11 Oct 2002 09:35:30 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection In-Reply-To: <3DA58164.2080709@nc.rr.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, 10 Oct 2002, Brian Haberman wrote: > >>I'm not worried about this. We have exactly the same issue for routing table > >>lookup in hosts and routers; there is no specification that states how > >>to implement caching schemes. > > > > > > We haven't really specified the source address selection like this for > > IPv4 either, I believe. Have I missed something? > > > > Routing table lookup is very simple compared to this I think. > > Have you looked at the routing/forwarding sections of the scoped > addressing architecture? It used to be simple. It has seemed relatively simple to me, except for the parts with site-local addressing.. :-( -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 10 23:55:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6t129023598; Thu, 10 Oct 2002 23:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9B6t1PI023597; Thu, 10 Oct 2002 23:55:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9B6sw29023590 for ; Thu, 10 Oct 2002 23:54:58 -0700 (PDT) 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 g9B6t4PG021430 for ; Thu, 10 Oct 2002 23:55:04 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27556 for ; Thu, 10 Oct 2002 23:54:58 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9B6suE17619; Fri, 11 Oct 2002 09:54:56 +0300 Date: Fri, 11 Oct 2002 09:54:55 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection 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, 10 Oct 2002, Erik Nordmark wrote: > > We haven't really specified the source address selection like this for > > IPv4 either, I believe. Have I missed something? > > That wasn't what I said. I said that IETF specifications don't > go into details on how to cache things, whether it is for "routing" > or "source address selection". Perhaps we should have been more careful when discussing "how/when" to use caching. But well, 'htsearch' on RFC's for "cache" at http://rfc.eunet.fi (for example) returns 520 RFC's. I think there are examples of some caching specification, as well (e.g. neighbor discovery, multicast, ...). The level of detail is of course imporant. At least, very many specifications say, like "this and this part is critical and should [or SHOULD] be cached". One of my main worries was that it seemed that nobody even bothered to mention that the steps could be complex and some caching mechanism (possibly with some examples) should be implemented. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 03:44:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BAig29024373; Fri, 11 Oct 2002 03:44:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BAifi9024372; Fri, 11 Oct 2002 03:44:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BAic29024365 for ; Fri, 11 Oct 2002 03:44:38 -0700 (PDT) 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 g9BAihPG018033 for ; Fri, 11 Oct 2002 03:44:44 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21416 for ; Fri, 11 Oct 2002 03:44:37 -0700 (PDT) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP9063HQ; Fri, 11 Oct 2002 16:14:56 +0530 Received: from netlab.hcltech.com ([192.168.19.129]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id QAA12386 for ; Fri, 11 Oct 2002 16:43:20 +0530 Message-ID: <3DA6EB11.CA525C81@netlab.hcltech.com> Date: Fri, 11 Oct 2002 16:15:29 +0100 From: Arun Prasad X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: scope id querry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Some doubts on the socket api for Ipv6. * When a IPV6 packet is received throught the interface "recvmsg", how to get the "zone_id" or "scope_id" for the received Ipv6 Addr. When the "recvmsg" interface is called we get a structure in6_pktinfo, which has the ipv6 address and "ipi6_ifindex".... Does this "ipi6_ifindex" serve as "zone_id". Please clarify. Thanks -arun -- **************************************************************** V.ARUN PRASAD HCL Technologies Ltd., Networking Technologies Lab, Ground Floor, Block - 1, Chandamama Building, 184 to 188,190,192 & 196, NSK Road, Vadapalani, Chennai - 600 026 Phone: Off: +91-44-3728366/67/69, +91-44-3728156/57 Extn. 1133 Fax: +91-44-4806640 **************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 08:11:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFBD29025595; Fri, 11 Oct 2002 08:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BFBDeI025594; Fri, 11 Oct 2002 08:11:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFB929025580 for ; Fri, 11 Oct 2002 08:11:09 -0700 (PDT) Received: from localhost (lillen.France.Sun.COM [129.157.212.23]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9BFBBQl732575; Fri, 11 Oct 2002 08:11:12 -0700 (PDT) Date: Fri, 11 Oct 2002 15:15:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multihomed host To: William Waites Cc: Bill Sommerfeld , Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <86smzecevt.fsf@styx.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This just looks like the degenerate case -- multiple addresses, > multiple interfaces, except that each of the multiple interfaces > happen to be the same. It seems to me that the network layer code > should treat both cases identically. Does this make sense? There are some important differences when it comes to the relationship between IP source address and routes that are used. draft-ietf-ipv6-default-addr-select-09.txt specifies that the candidate source address are related to the interface on which a packet is sent. Hence there is a difference between case 1: Host with one interface, two routers, two global addresses with different prefixes (whether one router advertises each addrconf prefix or both routers advertise both prefixes). In this case the candidate source address will be both global addresses, and the other rules in the source address selection will determine which source address is used. Note that there is no relationship between the source address selected and which (default) router is used for sending packets. case 2: Host with two interface, one router on each interface, one global address being configured on each interface with different prefixes (each router advertises a single addrconf prefix) In this case the candidate source address set will be coupled to the (default) route used to send the packet, since there are two interfaces. In both cases there are issues of what happens when e.g. one of the routers fail, which have to do with not only how the host behaves but also how routing works beyond the first hop routers. 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 Oct 11 08:11:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFBM29025618; Fri, 11 Oct 2002 08:11:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BFBMl8025617; Fri, 11 Oct 2002 08:11:22 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFBE29025597; Fri, 11 Oct 2002 08:11:14 -0700 (PDT) Received: from localhost (lillen.France.Sun.COM [129.157.212.23]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9BFBHQl732593; Fri, 11 Oct 2002 08:11:18 -0700 (PDT) Date: Fri, 11 Oct 2002 15:35:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Query about automatic tunneling and ND To: Anurag Uxa Cc: alh-ietf@tndh.net, "'Pekka Savola'" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <006101c270e4$4cd61c70$b202a8c0@iwave120> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [RFC2893] SHOULD also send NUD probe packets to detect when the configured > tunnel fails at which point the implementation can use an alternate path to > reach the destination. The above refers to configured tunnels, and your question seems to be about the automatic tunnels specified in RFC 2893. I don't interpret RFC 2893 to recommend doing NUD on its automatic tunnels. Furthermore, the upcoming revision to RFC 2893 is removing support for automatic tunneling since the RFC 3056 6to4 tunnels provides a superset. 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 Oct 11 08:11:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFBH29025605; Fri, 11 Oct 2002 08:11:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BFBG87025604; Fri, 11 Oct 2002 08:11:16 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFBB29025587 for ; Fri, 11 Oct 2002 08:11:11 -0700 (PDT) Received: from localhost (lillen.France.Sun.COM [129.157.212.23]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9BFBEQl732586; Fri, 11 Oct 2002 08:11:15 -0700 (PDT) Date: Fri, 11 Oct 2002 15:28:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: question on next-hop determination To: Qing Li Cc: Thomas Narten , 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 > I think the sending host should just drop the packet when the > destination is not covered in its prefix list and there is > no default route installed. Otherwise IMHO this last attempt > would lead to erroneous packet generation, and allows > misconfigured host or host running a buggy implementation to > continue with bad behavior. Imagine a case when host1 and host2 are on the same link, but DHCPv6 has given them different /64 prefixes for some reason. The routers have been configured to not advertise any on-link prefixes i.e. the hosts send packets to the router and get redirected to the on-link destination. The communicate fine as long as the router is around. When the router fails this communication local to the link would fail, unless the fallback to treat all destinations as on-link is in place. A less esoteric example is when the hosts are in the same prefix, and either no on-link prefix is advertised (no 'O' bit in the prefix advertisement) or the on-link prefix expires in relatively short time i.e. the hosts quickly forget which destinations are on-link. > Also the code put in to supporting this looks and feels > like hacks. That seems like a comment for the implementors of whatever implementation you are looking at, and not a comment relating to the RFC. 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 Oct 11 08:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFGb29025875; Fri, 11 Oct 2002 08:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BFGbKk025874; Fri, 11 Oct 2002 08:16:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFGX29025864 for ; Fri, 11 Oct 2002 08:16:33 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01921; Fri, 11 Oct 2002 11:16:38 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id g9BFGbqG020068; Fri, 11 Oct 2002 11:16:37 -0400 (EDT) Message-Id: <200210111516.g9BFGbqG020068@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Pekka Savola cc: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= , ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: Implementation worries about default address selection In-Reply-To: Message from Pekka Savola of "Fri, 11 Oct 2002 09:24:04 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Oct 2002 11:16:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk pekkas@netcore.fi said: > > |5. Source Address Selection > > | > > | The source address selection algorithm produces as output a single > > | source address for use with a given destination address. This > > Yes, that is clear (the algorithm must have only one destination), but the > question arises how much this makes sense (as the destination address may > already have been selected using some arbitrary source address for > comparing against the destination address). I'm not sure I understand your last parenthesized comment. Are you worried that an application could choose a destination address based on source address assumptions that are different than those of the kernel's default source address selection mechanism? In that case, the application should bind to the source address to be sure it gets the one it wants right? I could be misunderstanding what you've said. > > The extra steps may not harm of course (extra work..). One possibly > interesting scenario could be when source or destination address selection > has been upgraded to honor this but the other isn't. The source address selection mechanism is still useful in the absence of the destination address ordering. In any case, there is no guarantee that applications will use the destination addresses in the order returned from name lookups. Also, users or administrators may want the ability to turn off the destination address ordering mechanism in order to preserve some sort of ordering returned by the server (DNS round-robin for example). The destination address ordering mechanism needs some deterministic source address mechanism to use as input, otherwise only rules 1, 6, 7, and 8 make any sense. So perhaps a subset of the destination address ordering mechanism would be useful without the source address selection bits. -Sebastien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 08:24:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFOS29026114; Fri, 11 Oct 2002 08:24:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BFOSgS026113; Fri, 11 Oct 2002 08:24:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BFOO29026103 for ; Fri, 11 Oct 2002 08:24:24 -0700 (PDT) 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 g9BFOTPG023632 for ; Fri, 11 Oct 2002 08:24:30 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05196; Fri, 11 Oct 2002 09:24:23 -0600 (MDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g9BFOKw05150; Fri, 11 Oct 2002 10:24:21 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3DA6ED24.7000704@stewart.chicago.il.us> Date: Fri, 11 Oct 2002 10:24:20 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: >>We haven't really specified the source address selection like this for >>IPv4 either, I believe. Have I missed something? > > > That wasn't what I said. I said that IETF specifications don't > go into details on how to cache things, whether it is for "routing" > or "source address selection". > > I suspect IPv4 implementations which allow more than one IP address > per interface have some mechanism by which the source IP address > is selected, since it can't just be the single IP address assigned to > the outgoing interface. > > Having implemented this for SCTP I can tell you that normally if more than one address exists for an interface you end up picking the first source address on the interface (assuming it is not restricted i.e. the application has this address in its bound list and the peer knows about the address). This works for both V6 and V4 and scoping must be done for both V4 and V6 addresses... since we have this little ugly thing called NAT in V4.... Generally you do the route lookup and then cache the route. The route has a pointer to the interface and you pick up the first address on the interface.. not complex but it can get tricky when the first address is restricted :-0 >>Routing table lookup is very simple compared to this I think. > > > Conceptually simple, yes. Making it perform, combining the routing table > with the arp/nd cache for performance, etc makes it more complex. > Source address selection is also conceptually simple. And making it > perform well makes life more complex. > You got that right :-0 R > 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 > -------------------------------------------------------------------- > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 09:04:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BG4c29026356; Fri, 11 Oct 2002 09:04:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BG4c2B026355; Fri, 11 Oct 2002 09:04:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BG4Y29026348 for ; Fri, 11 Oct 2002 09:04:34 -0700 (PDT) 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 g9BG4dPG001454 for ; Fri, 11 Oct 2002 09:04:39 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06379; Fri, 11 Oct 2002 10:04:33 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9BG4V027787; Fri, 11 Oct 2002 12:04:31 -0400 (EDT) Message-Id: <200210111604.g9BG4V027787@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Sebastien Roy cc: Pekka Savola , YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection In-reply-to: (Your message of "Fri, 11 Oct 2002 11:16:37 EDT.") <200210111516.g9BFGbqG020068@strat.East.Sun.COM> Date: Fri, 11 Oct 2002 12:04:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In any case, there is no > guarantee that applications will use the destination addresses in the > order returned from name lookups. that's okay, the idea that DNS knows which addresses are better is a delusion anyway. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 10:01:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BH1229026771; Fri, 11 Oct 2002 10:01:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BH12uY026770; Fri, 11 Oct 2002 10:01:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BH0x29026763 for ; Fri, 11 Oct 2002 10:00:59 -0700 (PDT) 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 g9BH14PG014490 for ; Fri, 11 Oct 2002 10:01:04 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10502 for ; Fri, 11 Oct 2002 10:00:59 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.233.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA16319; Fri, 11 Oct 2002 09:59:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Oct 2002 13:01:52 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: "Dave Thaler" , "Brian Haberman" , ipng@sunroof.eng.sun.com In-Reply-To: <9072.1034274308@munnari.OZ.AU> References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:25 PM 10/10/02, Robert Elz wrote: >So would I. The change I would make is to delete all references >of subnet-local from the addr-arch doc, and simply leave those values >as "to be defined" and then define them in the scoping-arch doc. This seems reasonable to me. It moves this issue out of the IPv6 addr arch, allowing that document to move ahead, and let's us work out the details in the scoped addr arch and/or the multi-link subnets doc. Good idea, Robert. What do other folks think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 10:26:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BHQI29026924; Fri, 11 Oct 2002 10:26:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BHQIqt026923; Fri, 11 Oct 2002 10:26:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BHQD29026916 for ; Fri, 11 Oct 2002 10:26:13 -0700 (PDT) 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 g9BHQDPG020895 for ; Fri, 11 Oct 2002 10:26:13 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22199 for ; Fri, 11 Oct 2002 11:26:08 -0600 (MDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9BHPviZ021756 for ; Fri, 11 Oct 2002 13:25:57 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 11 Oct 2002 13:26:09 -0400 Message-ID: <3DA70A62.3000601@nc.rr.com> Date: Fri, 11 Oct 2002 13:29:06 -0400 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > At 02:25 PM 10/10/02, Robert Elz wrote: > >> So would I. The change I would make is to delete all references >> of subnet-local from the addr-arch doc, and simply leave those values >> as "to be defined" and then define them in the scoping-arch doc. > > > This seems reasonable to me. > > It moves this issue out of the IPv6 addr arch, allowing that document > to move ahead, and let's us work out the details in the scoped addr > arch and/or the multi-link subnets doc. > > Good idea, Robert. > > What do other folks think? I would go a step further. Since almost no one has implemented the routing/forwarding of scoped addresses (multicast & unicast site locals), I recommend: 1. Move all discussion of multicast scopes out of the addr-arch and into the scoped addr-arch doc 2. Move all text on site-local unicasts out of the addr-arch doc and into the scoped addr-arch doc 3. Add explicit text to the scoped addr-arch doc to define how/when/where these scopes should be used This would allow the addr-arch doc to progress to DS without being hung up on text involving scoped addresses but still describing the pieces that we know work (e.g. global and link-local). It would also make a clean delineation between global and scoped addresses. The scoped addr-arch doc can then be the home for future work on scoped addresses. My reasoning is based on actually having implemented scoped routing and forwarding. It is not trivial or for the weak of heart. 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 Oct 11 11:17:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BIHQ29027465; Fri, 11 Oct 2002 11:17:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BIHQqK027464; Fri, 11 Oct 2002 11:17:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BIHM29027457 for ; Fri, 11 Oct 2002 11:17:23 -0700 (PDT) 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 g9BIHRPG004128 for ; Fri, 11 Oct 2002 11:17:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15506 for ; Fri, 11 Oct 2002 12:17:20 -0600 (MDT) Message-ID: <010601c27152$45a84db0$3c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: , "Richard Nelson" Cc: "Thomas Narten" , References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> <3DA6563B.9070605@eng.monash.edu.au> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Fri, 11 Oct 2002 11:15:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg, > I'd just like to indicate that we have seen the delay > for router advertisement to be a significant delay > in MIPv6 handovers, since there is no DAD in the case > where a mobile node moves back to a previously visited > network. How is that so? Of course the chances of some other node claiming your node's IP address while it's gone are even less, but still it is not impossible. So, you can choose to not use DAD by taking this risk... Is this what you mean? alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 11:56:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BIuJ29027596; Fri, 11 Oct 2002 11:56:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BIuJVk027595; Fri, 11 Oct 2002 11:56:19 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BIuG29027588 for ; Fri, 11 Oct 2002 11:56:16 -0700 (PDT) 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 g9BIuLMq009423 for ; Fri, 11 Oct 2002 11:56:22 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27935 for ; Fri, 11 Oct 2002 12:56:16 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3DF3318AE for ; Fri, 11 Oct 2002 14:56:14 -0400 (EDT) Date: Fri, 11 Oct 2002 14:56:14 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <3DA70A62.3000601@nc.rr.com> References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> <3DA70A62.3000601@nc.rr.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021011185614.3DF3318AE@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Both Robert's approach and Brian's approach seem workable. Of the two, I think Brian's approach is better, because it collects the scoped address stuff in one place, which seems good on several counts. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 12:02:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BJ2s29027652; Fri, 11 Oct 2002 12:02:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BJ2sop027651; Fri, 11 Oct 2002 12:02:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BJ2o29027644 for ; Fri, 11 Oct 2002 12:02:50 -0700 (PDT) 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 g9BJ2tPG015013 for ; Fri, 11 Oct 2002 12:02:55 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24969 for ; Fri, 11 Oct 2002 12:02:50 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9BIwr003508; Fri, 11 Oct 2002 14:58:53 -0400 (EDT) Message-Id: <200210111858.g9BIwr003508@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Robert Elz , "Dave Thaler" , "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Fri, 11 Oct 2002 13:01:52 EDT.") <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> Date: Fri, 11 Oct 2002 14:58:53 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What do other folks think? I think we need to all but deprecate scoped addresses except for a few limited purposes such as autoconfiguration and disconnected operation. Trying to make them work in a general purpose fashion places an untenable burden on hosts and applications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 14:14:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLE329028437; Fri, 11 Oct 2002 14:14:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BLE3MI028436; Fri, 11 Oct 2002 14:14:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLDx29028429 for ; Fri, 11 Oct 2002 14:13:59 -0700 (PDT) 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 g9BLE4PG016476 for ; Fri, 11 Oct 2002 14:14:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20811 for ; Fri, 11 Oct 2002 15:13:58 -0600 (MDT) 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 OAA18233; Fri, 11 Oct 2002 14:13:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9BLDu807990; Fri, 11 Oct 2002 14:13:56 -0700 X-mProtect: <200210112113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdo3EGGz; Fri, 11 Oct 2002 14:13:54 PDT Message-Id: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 14:13:45 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : Well known site local unicast addresses for DNS resolver Author(s) : A. Durand, J. Hagino, D. Thaler Filename : draft-ietf-ipv6-dns-discovery-06.txt Pages : 12 Date : 2002-9-19 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will on 25 October, 2002. Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 14:29:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLTC29028538; Fri, 11 Oct 2002 14:29:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BLTC7h028537; Fri, 11 Oct 2002 14:29:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLT929028530 for ; Fri, 11 Oct 2002 14:29:09 -0700 (PDT) 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 g9BLTEPG020325 for ; Fri, 11 Oct 2002 14:29:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13582 for ; Fri, 11 Oct 2002 14:29:09 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9BLT7h02057; Fri, 11 Oct 2002 14:29:07 -0700 (PDT) From: Bill Manning Message-Id: <200210112129.g9BLT7h02057@boreas.isi.edu> Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> from Bob Hinden at "Oct 11, 2 02:13:45 pm" To: hinden@iprg.nokia.com (Bob Hinden) Date: Fri, 11 Oct 2002 14:29:07 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk what does the DNS mafia/directorate think of this goofy idea? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 14:34:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLYw29028582; Fri, 11 Oct 2002 14:34:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BLYwCL028581; Fri, 11 Oct 2002 14:34:58 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLYs29028574 for ; Fri, 11 Oct 2002 14:34:54 -0700 (PDT) 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 g9BLZ0Mq021717 for ; Fri, 11 Oct 2002 14:35:00 -0700 (PDT) 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 OAA17605 for ; Fri, 11 Oct 2002 14:34:54 -0700 (PDT) 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 OAA19419; Fri, 11 Oct 2002 14:34:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9BLYrE31796; Fri, 11 Oct 2002 14:34:53 -0700 X-mProtect: <200210112134> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQyomkd; Fri, 11 Oct 2002 14:34:50 PDT Message-Id: <4.3.2.7.2.20021011141910.02fa2130@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 14:34:41 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> References: <9072.1034274308@munnari.OZ.AU> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:01 AM 10/11/2002, Margaret Wasserman wrote: >At 02:25 PM 10/10/02, Robert Elz wrote: >>So would I. The change I would make is to delete all references >>of subnet-local from the addr-arch doc, and simply leave those values >>as "to be defined" and then define them in the scoping-arch doc. > >This seems reasonable to me. To clarify this, I think the proposal is to change the definition of the multicast scope value 3 from "subnet-local scope" to "unassigned". The table in section 2.7 Multicast Addresses would be changed to: scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 1 interface-local scope 2 link-local scope 3 (unassigned) 4 admin-local scope 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved Also, the definition of subnet-local multicast scope that follows would be removed. If there is agreement to make this change, I could issue a new draft next week. This should resolve the issue that Rob Austen raised. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 14:52:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLqZ29028833; Fri, 11 Oct 2002 14:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BLqYIG028832; Fri, 11 Oct 2002 14:52:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BLqV29028825 for ; Fri, 11 Oct 2002 14:52:31 -0700 (PDT) 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 g9BLqaMq026140 for ; Fri, 11 Oct 2002 14:52:36 -0700 (PDT) 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 OAA06753 for ; Fri, 11 Oct 2002 14:52:31 -0700 (PDT) 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 OAA20207; Fri, 11 Oct 2002 14:52:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9BLqUH21099; Fri, 11 Oct 2002 14:52:30 -0700 X-mProtect: <200210112152> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2ChTjK; Fri, 11 Oct 2002 14:52:29 PDT Message-Id: <4.3.2.7.2.20021011143556.02dcd730@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 14:52:20 -0700 To: Brian Haberman From: Bob Hinden Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DA70A62.3000601@nc.rr.com> References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I think this goes to far. We have recently had a long discussion on the list regarding unicast site-local that concluded with keeping the definition of unicast site-local addresses in the document (see my email on 21 Jun 2002, titled "Consensus on Site-Local Discussion"). Part of that was that we would add text to the Node Requirements document that nodes are only required to implement the rules specified in the default address selection document (now a Proposed Standard) and that there be no requirement that a node must be able to be part of more than one zone. Bob >I would go a step further. Since almost no one has implemented the >routing/forwarding of scoped addresses (multicast & unicast site >locals), I recommend: > > 1. Move all discussion of multicast scopes out of the addr-arch > and into the scoped addr-arch doc > 2. Move all text on site-local unicasts out of the addr-arch > doc and into the scoped addr-arch doc > 3. Add explicit text to the scoped addr-arch doc to define > how/when/where these scopes should be used > >This would allow the addr-arch doc to progress to DS without being >hung up on text involving scoped addresses but still describing the >pieces that we know work (e.g. global and link-local). It would also >make a clean delineation between global and scoped addresses. > >The scoped addr-arch doc can then be the home for future work on >scoped addresses. > >My reasoning is based on actually having implemented scoped routing >and forwarding. It is not trivial or for the weak of heart. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 15:08:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BM8X29028995; Fri, 11 Oct 2002 15:08:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BM8XsH028994; Fri, 11 Oct 2002 15:08:33 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BM8U29028987 for ; Fri, 11 Oct 2002 15:08:30 -0700 (PDT) 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 g9BM8ZMq000470 for ; Fri, 11 Oct 2002 15:08:35 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11656 for ; Fri, 11 Oct 2002 15:08:29 -0700 (PDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9BM8FiZ007782; Fri, 11 Oct 2002 18:08:15 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 11 Oct 2002 18:08:23 -0400 Message-ID: <3DA74B3E.B3CE8ED9@nc.rr.com> Date: Fri, 11 Oct 2002 18:05:50 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> <4.3.2.7.2.20021011143556.02dcd730@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, What about all the multicast scopes? And will the new text in the Node Requirements document apply to routers? That is where many of the issues arise with site-locals. I won't even bring up the issues with DNS and site-locals. My point is that I believe that a clean separation should be made between global addresses and scoped addresses. We fully understand how globals and link-locals work. All the others are still being hashed out. If we make this break, the address architecture can move along the standards track. The (great amount of) additional work that needs to be done on scoped addresses can be carried out under the scoped address architecture. Brian Bob Hinden wrote: > > Brian, > > I think this goes to far. We have recently had a long discussion on the > list regarding unicast site-local that concluded with keeping the > definition of unicast site-local addresses in the document (see my email on > 21 Jun 2002, titled "Consensus on Site-Local Discussion"). Part of that > was that we would add text to the Node Requirements document that nodes are > only required to implement the rules specified in the default address > selection document (now a Proposed Standard) and that there be no > requirement that a node must be able to be part of more than one zone. > > Bob > > >I would go a step further. Since almost no one has implemented the > >routing/forwarding of scoped addresses (multicast & unicast site > >locals), I recommend: > > > > 1. Move all discussion of multicast scopes out of the addr-arch > > and into the scoped addr-arch doc > > 2. Move all text on site-local unicasts out of the addr-arch > > doc and into the scoped addr-arch doc > > 3. Add explicit text to the scoped addr-arch doc to define > > how/when/where these scopes should be used > > > >This would allow the addr-arch doc to progress to DS without being > >hung up on text involving scoped addresses but still describing the > >pieces that we know work (e.g. global and link-local). It would also > >make a clean delineation between global and scoped addresses. > > > >The scoped addr-arch doc can then be the home for future work on > >scoped addresses. > > > >My reasoning is based on actually having implemented scoped routing > >and forwarding. It is not trivial or for the weak of heart. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 15:12:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BMCh29029069; Fri, 11 Oct 2002 15:12:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BMCh3l029068; Fri, 11 Oct 2002 15:12:43 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BMCe29029058; Fri, 11 Oct 2002 15:12:40 -0700 (PDT) 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 g9BMCiMq001418; Fri, 11 Oct 2002 15:12:44 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00063; Fri, 11 Oct 2002 16:12:37 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9BM9Iov008512; Fri, 11 Oct 2002 15:09:18 -0700 (PDT) Received: from [171.71.119.37] (dhcp-171-71-119-37.cisco.com [171.71.119.37]) by mira-sjcd-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ACT20851; Fri, 11 Oct 2002 15:07:20 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: Date: Fri, 11 Oct 2002 15:09:22 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, members@ipv6forum.com, , end2end-tf@ISI.EDU From: Steve Deering Subject: Sabbatical Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [my apologies for any duplicates] Dear Colleagues/Friends, This note is to let you know that, starting next week, I am taking an extended leave of absence from Cisco and from the IETF. After eighteen very rewarding years of participation in the IETF, the last eleven of which have been spent helping to bring the new version of IP to the Internet, it seems like a good time to take a nice, long break from the world of email, airplanes, and protocol politics. I plan to spend at least a year pursuing other personal interests that have absolutely nothing to do with the Internet (mostly involving hiking boots and a camera). Beyond that, I have no specific plans at the moment, but my employer has generously granted me a leave of absence for now, so that if I find the PowerPoint withdrawal unbearable, they'll let me come back. I am gratified at how far we have come with IPv6. We have a set of specifications that have been widely implemented and well tested, and they continue to be refined and extended with the enthusiastic participation of many volunteers. There are high-quality implementations of the protocol available for almost all routers and host operating systems (including, at last, one for us discerning Macintosh users!). It is widely deployed in many research and education networks, and the first commercial IPv6 networks are up and running. And the address allocation procedures and policies are in place to ensure that all those new addresses we made can actually be used as intended! I am proud to have learned from, collaborated with, and befriended the many people who have participated -- and who will continue to participate, I hope -- in this grand project to ensure that all the benefits of the Internet become available to everyone -- not just the lucky ones who got the IPv4 addresses! There is still lots of work to be done, of course, but most of that is in the areas of applications, "middleware", network management, and cool new devices, which is to say, not my layer! :-) The remaining internet-layer work of the IPv6 Working Group will continue under the respected and experienced leadership of Bob Hinden and Margaret Wasserman. I am honored to have served on the IAB and to have had the privilege of getting to know and learn from the many smart and selfless IETFers who have served on that body. I am also grateful to the IAB for letting me escape without quite finishing out my term! Some bureaucratic details: My resignation from the IPv6 WG co-chair position and the IAB is effective at the end of next week, giving me time to try to clean up a few loose ends. After that, I will be unsubscribing from most mailing lists (ahhhh). Personal email to deering@cisco.com should still reach me, sometimes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 16:06:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BN6m29029608; Fri, 11 Oct 2002 16:06:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BN6ltt029607; Fri, 11 Oct 2002 16:06:47 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BN6h29029600 for ; Fri, 11 Oct 2002 16:06:43 -0700 (PDT) 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 g9BN6nMq014907 for ; Fri, 11 Oct 2002 16:06:49 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24288 for ; Fri, 11 Oct 2002 17:06:42 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9BN6V004831; Fri, 11 Oct 2002 19:06:31 -0400 (EDT) Message-Id: <200210112306.g9BN6V004831@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Fri, 11 Oct 2002 18:05:50 EDT.") <3DA74B3E.B3CE8ED9@nc.rr.com> Date: Fri, 11 Oct 2002 19:06:31 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My point is that I believe that a clean separation should be made > between global addresses and scoped addresses. We fully understand > how globals and link-locals work. All the others are still being > hashed out. If we make this break, the address architecture can > move along the standards track. The (great amount of) additional > work that needs to be done on scoped addresses can be carried out > under the scoped address architecture. actually I'd claim that we don't really understand how link-locals work, at least not from the applications viewpoint. but I enthusiastically support the idea of separating the work on globals from the work on scoped addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 16:35:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BNZZ29029832; Fri, 11 Oct 2002 16:35:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9BNZZSs029831; Fri, 11 Oct 2002 16:35:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9BNZW29029824 for ; Fri, 11 Oct 2002 16:35:32 -0700 (PDT) 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 g9BNZbPG021051 for ; Fri, 11 Oct 2002 16:35:37 -0700 (PDT) Received: from mail010.syd.optusnet.com.au (mail010.syd.optusnet.com.au [210.49.20.138]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02701 for ; Fri, 11 Oct 2002 17:35:31 -0600 (MDT) Received: from co3016429a (c17345.lowrp1.vic.optusnet.com.au [210.49.213.205]) by mail010.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g9BNZJF28505; Sat, 12 Oct 2002 09:35:19 +1000 Message-ID: <007501c2717f$640723d0$cdd531d2@co3016429a> From: "Richard Nelson" To: "Alper E. YEGIN" , Cc: "Thomas Narten" , References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> <3DA6563B.9070605@eng.monash.edu.au> <010601c27152$45a84db0$3c6015ac@AlperVAIO> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Sat, 12 Oct 2002 09:39:05 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The short answer is that that is what Linux/MIPL does. We haven't changed anything. The slightly longer answer is that RFCs2461/2462 describe how prefixes are advertised with a valid lifetime and that addresses take on that lifetime and can be used until that lifetime expires. RFC2461 specifically describes the case where a laptop is unplugged and is entitled to use its previous address when plugged in again. The default value for lifetimes is 30 days and infinity is a valid value. Richard. ----- Original Message ----- From: "Alper E. YEGIN" To: ; "Richard Nelson" Cc: "Thomas Narten" ; Sent: Saturday, October 12, 2002 4:15 AM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > Greg, > > > I'd just like to indicate that we have seen the delay > > for router advertisement to be a significant delay > > in MIPv6 handovers, since there is no DAD in the case > > where a mobile node moves back to a previously visited > > network. > > How is that so? Of course the chances of some other > node claiming your node's IP address while it's gone > are even less, but still it is not impossible. So, you can > choose to not use DAD by taking this risk... Is this what > you mean? > > alper > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 17:13:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C0DZ29000004; Fri, 11 Oct 2002 17:13:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9C0DZtf029999; Fri, 11 Oct 2002 17:13:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C0DW29029992 for ; Fri, 11 Oct 2002 17:13:32 -0700 (PDT) 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 g9C0DbPG028722 for ; Fri, 11 Oct 2002 17:13:37 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28757 for ; Fri, 11 Oct 2002 17:13:32 -0700 (PDT) Message-ID: <01d001c27184$005753a0$3c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Richard Nelson" , Cc: "Thomas Narten" , References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> <3DA6563B.9070605@eng.monash.edu.au> <010601c27152$45a84db0$3c6015ac@AlperVAIO> <007501c2717f$640723d0$cdd531d2@co3016429a> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Fri, 11 Oct 2002 17:11:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The short answer is that that is what Linux/MIPL does. We haven't changed > anything. > The slightly longer answer is that RFCs2461/2462 describe how prefixes are > advertised with a valid lifetime > and that addresses take on that lifetime and can be used until that lifetime > expires. RFC2461 specifically describes the case where a laptop is > unplugged and is entitled to use its previous address when plugged in again. > The default value for lifetimes is 30 days and infinity is a valid value. This lifetime is about "prefix validity". Not "ownership of an IP address configured based on this prefix". Any node can attempt to configure any IP address with a valid prefix. Unless there is another node defending this address, DAD succeeds, hence IP address is configured. In the case of your mobile node being away for a while, anyone else can claim it's care-of address and configure it in the absence of your node defending it. (of course, if there is a home agent on that link, with this IP address in its binding cache as the home address of a mobile node, then this home agent can defend the address. this would be the case if your mobile node is using forwarding from previous care-of address technique when it moved to the other visited network) alper > > Richard. > > ----- Original Message ----- > From: "Alper E. YEGIN" > To: ; "Richard Nelson" > > Cc: "Thomas Narten" ; > Sent: Saturday, October 12, 2002 4:15 AM > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > > Greg, > > > > > I'd just like to indicate that we have seen the delay > > > for router advertisement to be a significant delay > > > in MIPv6 handovers, since there is no DAD in the case > > > where a mobile node moves back to a previously visited > > > network. > > > > How is that so? Of course the chances of some other > > node claiming your node's IP address while it's gone > > are even less, but still it is not impossible. So, you can > > choose to not use DAD by taking this risk... Is this what > > you mean? > > > > alper > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 19:21:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C2L629000376; Fri, 11 Oct 2002 19:21:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9C2L6KQ000375; Fri, 11 Oct 2002 19:21:06 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C2L329000368 for ; Fri, 11 Oct 2002 19:21:03 -0700 (PDT) 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 g9C2L8Mq021943 for ; Fri, 11 Oct 2002 19:21:08 -0700 (PDT) Received: from mail015.syd.optusnet.com.au (mail015.syd.optusnet.com.au [210.49.20.173]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03377 for ; Fri, 11 Oct 2002 19:21:03 -0700 (PDT) Received: from co3016429a (c17345.lowrp1.vic.optusnet.com.au [210.49.213.205]) by mail015.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g9C2Ktu02896; Sat, 12 Oct 2002 12:20:56 +1000 Message-ID: <009501c27196$85dab050$cdd531d2@co3016429a> From: "Richard Nelson" To: "Alper E. YEGIN" , Cc: "Thomas Narten" , References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> <3DA6563B.9070605@eng.monash.edu.au> <010601c27152$45a84db0$3c6015ac@AlperVAIO> <007501c2717f$640723d0$cdd531d2@co3016429a> <01d001c27184$005753a0$3c6015ac@AlperVAIO> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Sat, 12 Oct 2002 12:24:41 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What you say is correct of course, but it does not seem to be what current implementations actually do. RFC 2462 says "Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface..." If a node returns to an already visited network for which it has defended an address, does using it again consist of "assigning" it to the interface? As you say there is a case why it should, but current implementations, at least those with which we are familiar, don't work that way. Richard. ----- Original Message ----- From: "Alper E. YEGIN" To: "Richard Nelson" ; Cc: "Thomas Narten" ; Sent: Saturday, October 12, 2002 10:11 AM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > > The short answer is that that is what Linux/MIPL does. We haven't changed > > anything. > > The slightly longer answer is that RFCs2461/2462 describe how prefixes are > > advertised with a valid lifetime > > and that addresses take on that lifetime and can be used until that > lifetime > > expires. RFC2461 specifically describes the case where a laptop is > > unplugged and is entitled to use its previous address when plugged in > again. > > The default value for lifetimes is 30 days and infinity is a valid value. > > This lifetime is about "prefix validity". Not "ownership > of an IP address configured based on this prefix". > > Any node can attempt to configure any IP address > with a valid prefix. Unless there is another node > defending this address, DAD succeeds, hence IP > address is configured. > > In the case of your mobile node being away for a while, > anyone else can claim it's care-of address and configure > it in the absence of your node defending it. > > (of course, if there is a home agent on that link, with > this IP address in its binding cache as the home address > of a mobile node, then this home agent can defend the address. > this would be the case if your mobile node is using forwarding > from previous care-of address technique when it moved > to the other visited network) > > alper > > > > > > > > Richard. > > > > ----- Original Message ----- > > From: "Alper E. YEGIN" > > To: ; "Richard Nelson" > > > > Cc: "Thomas Narten" ; > > Sent: Saturday, October 12, 2002 4:15 AM > > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > > > > > Greg, > > > > > > > I'd just like to indicate that we have seen the delay > > > > for router advertisement to be a significant delay > > > > in MIPv6 handovers, since there is no DAD in the case > > > > where a mobile node moves back to a previously visited > > > > network. > > > > > > How is that so? Of course the chances of some other > > > node claiming your node's IP address while it's gone > > > are even less, but still it is not impossible. So, you can > > > choose to not use DAD by taking this risk... Is this what > > > you mean? > > > > > > alper > > > > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 19:54:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C2sP29000653; Fri, 11 Oct 2002 19:54:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9C2sPdE000652; Fri, 11 Oct 2002 19:54:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C2sM29000645 for ; Fri, 11 Oct 2002 19:54:22 -0700 (PDT) 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 g9C2sRPG022089 for ; Fri, 11 Oct 2002 19:54:28 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA21174 for ; Fri, 11 Oct 2002 20:54:20 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9C2qSF03747; Fri, 11 Oct 2002 22:52:29 -0400 Message-Id: <200210120252.g9C2qSF03747@cichlid.adsl.duke.edu> To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: Sabbatical In-Reply-To: Message from Steve Deering of "Fri, 11 Oct 2002 15:09:22 PDT." Date: Fri, 11 Oct 2002 22:52:28 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I am certain that I will be speaking for many in saying that you have certainly earned some time off and that your presence and contributions will be missed. I will very much miss working with you. Enjoy yourself and I look forward to having an opportunity to work with you again at some time in the future. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 11 20:59:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C3xq29001144; Fri, 11 Oct 2002 20:59:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9C3xqtJ001143; Fri, 11 Oct 2002 20:59:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C3xn29001136 for ; Fri, 11 Oct 2002 20:59:49 -0700 (PDT) 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 g9C3xsMq002128 for ; Fri, 11 Oct 2002 20:59:54 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20656 for ; Fri, 11 Oct 2002 21:59:49 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 39EAC18FA for ; Fri, 11 Oct 2002 23:59:45 -0400 (EDT) Date: Fri, 11 Oct 2002 23:59:45 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021012035945.39EAC18FA@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote: > > This is a IPv6 working group last call for comments on advancing the > following document as a Proposed Standard: > > Title: Well known site local unicast addresses for DNS resolver I have written about this document at some length before, so I will summarize rather than repeating the entire thing. In brief: My main objection was and remains that this mechanism, if used, moves state away from the endpoints and into the network in a way that cripples the resolver's ability to keep track of which of the name servers it is using are performing properly, since the binding between any particular well-known-address and the name server behind it might change at any time and since there is no mechanism by which the resolver can find out that such a change has taken place. Furthermore, since this mechanism has enough weaknesses that even its authors only suggest this mechanism be used as a last resort, I fail to see what real purpose this mechanism serves. Finally, I remain unconvinced that this is a problem that the IPv6 WG ought to be trying to solve at all. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 12 02:59:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C9xG29002481; Sat, 12 Oct 2002 02:59:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9C9xGXP002480; Sat, 12 Oct 2002 02:59:16 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9C9xD29002473 for ; Sat, 12 Oct 2002 02:59:13 -0700 (PDT) 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 g9C9xFMq013927 for ; Sat, 12 Oct 2002 02:59:15 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29749 for ; Sat, 12 Oct 2002 02:59:00 -0700 (PDT) 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 g9C9wJM09422; Sat, 12 Oct 2002 16:58:20 +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 g9C6hga17292; Sat, 12 Oct 2002 13:43:42 +0700 (ICT) From: Robert Elz To: "Dave Thaler" cc: "Brian Haberman" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1087450CE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1087450CE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Oct 2002 13:43:42 +0700 Message-ID: <17290.1034405022@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Oct 2002 09:44:06 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1087450CE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> | Then you'd be in violation of the scoped addr architecture doc, | since you're sharing the same global prefix (prefix2) across | two site zones. If that's what that doc says, then it needs to change. Trying to make a strict hierarchy out of the different kinds of addresses is neither necessary, nor desirable. Many sites will choose to implement it that way, but it shouldn't have to be required. If I have just a single point of external connectivity, and hence am getting just a single global prefix, there's no reason at all that I can't run multiple sites (in the sense of site local addressing) inside there - in fact I thought that was one of the original planned scenarios. Similarly, there's no reason that I can't run multiple global prefixes within one site. All the same should apply to subnets. I can understand if you don't want to (yet) define how to make some of these situations work, or if some (eg: routing) protocols don't want to support all of the possibilities. That's fine. But an addr architecture doc certainly shouldn't be banning any of them. 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 Sat Oct 12 06:40:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9CDeD29002916; Sat, 12 Oct 2002 06:40:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9CDeDea002915; Sat, 12 Oct 2002 06:40:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9CDeA29002908 for ; Sat, 12 Oct 2002 06:40:10 -0700 (PDT) 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 g9CDeFMq008415 for ; Sat, 12 Oct 2002 06:40:15 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13260 for ; Sat, 12 Oct 2002 07:40:10 -0600 (MDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9CDeJup009947 for ; Sat, 12 Oct 2002 09:40:20 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 12 Oct 2002 09:40:11 -0400 Message-ID: <3DA8259C.BD1C5CF@nc.rr.com> Date: Sat, 12 Oct 2002 09:37:32 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> <20021012035945.39EAC18FA@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob Austein wrote: > > At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote: > > > > This is a IPv6 working group last call for comments on advancing the > > following document as a Proposed Standard: > > > > Title: Well known site local unicast addresses for DNS resolver > > I have written about this document at some length before, so I will > summarize rather than repeating the entire thing. In brief: > > My main objection was and remains that this mechanism, if used, moves > state away from the endpoints and into the network in a way that > cripples the resolver's ability to keep track of which of the name > servers it is using are performing properly, since the binding between > any particular well-known-address and the name server behind it might > change at any time and since there is no mechanism by which the > resolver can find out that such a change has taken place. What if we applied the principles that Erik and I propose in draft-haberman-ipv6-anycast-rr-00.txt? That would allow for the resolver to bind an address for the server. 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 Sat Oct 12 07:12:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9CECo29003046; Sat, 12 Oct 2002 07:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9CECoo8003045; Sat, 12 Oct 2002 07:12:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9CECl29003038 for ; Sat, 12 Oct 2002 07:12:47 -0700 (PDT) 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 g9CECqPG028752 for ; Sat, 12 Oct 2002 07:12:52 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14793 for ; Sat, 12 Oct 2002 08:12:45 -0600 (MDT) 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 g9CEC8M29712; Sat, 12 Oct 2002 21:12:09 +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 g9CEBvF21376; Sat, 12 Oct 2002 21:11:58 +0700 (ICT) From: Robert Elz To: Brian Haberman cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <3DA74B3E.B3CE8ED9@nc.rr.com> References: <3DA74B3E.B3CE8ED9@nc.rr.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> <4.3.2.7.2.20021011143556.02dcd730@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Oct 2002 21:11:57 +0700 Message-ID: <21374.1034431917@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Oct 2002 18:05:50 -0400 From: Brian Haberman Message-ID: <3DA74B3E.B3CE8ED9@nc.rr.com> | What about all the multicast scopes? Multicast scopes I'm not so sure about, but site local in general should remain. That works, and is defined just fine. The issue with site local is deciding when it should be used, and how one discovers the address, which has nothing at all to do with the architecture of the addresses or their definition. That is, if you have such an address, and plan on using it, its properties are quite clear. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 13 14:34:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9DLYZ29006979; Sun, 13 Oct 2002 14:34:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9DLYZaw006978; Sun, 13 Oct 2002 14:34:35 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9DLYW29006971 for ; Sun, 13 Oct 2002 14:34:32 -0700 (PDT) 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 g9DLYcMq016456 for ; Sun, 13 Oct 2002 14:34:38 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14533 for ; Sun, 13 Oct 2002 15:34:32 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9DLYeup014194 for ; Sun, 13 Oct 2002 17:34:41 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 13 Oct 2002 17:34:25 -0400 Message-ID: <3DA9E64A.E753FAC3@nc.rr.com> Date: Sun, 13 Oct 2002 17:31:54 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt References: <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <2E33960095B58E40A4D3345AB9F65EC107384304@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.1.0.14.2.20021011130038.02f95090@mail.windriver.com> <4.3.2.7.2.20021011143556.02dcd730@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, I went back and re-read the thread you mention below. There is absolutely no reason why discussion of site-locals couldn't be moved to the scoped addressing architecture doc. It wouldn't affect the text needed in the Node Requirements draft and it would put all the scoped addressing discussion in one place. Regards, Brian Bob Hinden wrote: > > Brian, > > I think this goes to far. We have recently had a long discussion on the > list regarding unicast site-local that concluded with keeping the > definition of unicast site-local addresses in the document (see my email on > 21 Jun 2002, titled "Consensus on Site-Local Discussion"). Part of that > was that we would add text to the Node Requirements document that nodes are > only required to implement the rules specified in the default address > selection document (now a Proposed Standard) and that there be no > requirement that a node must be able to be part of more than one zone. > > Bob > > >I would go a step further. Since almost no one has implemented the > >routing/forwarding of scoped addresses (multicast & unicast site > >locals), I recommend: > > > > 1. Move all discussion of multicast scopes out of the addr-arch > > and into the scoped addr-arch doc > > 2. Move all text on site-local unicasts out of the addr-arch > > doc and into the scoped addr-arch doc > > 3. Add explicit text to the scoped addr-arch doc to define > > how/when/where these scopes should be used > > > >This would allow the addr-arch doc to progress to DS without being > >hung up on text involving scoped addresses but still describing the > >pieces that we know work (e.g. global and link-local). It would also > >make a clean delineation between global and scoped addresses. > > > >The scoped addr-arch doc can then be the home for future work on > >scoped addresses. > > > >My reasoning is based on actually having implemented scoped routing > >and forwarding. It is not trivial or for the weak of heart. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 13 16:06:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9DN6r29007159; Sun, 13 Oct 2002 16:06:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9DN6rHB007158; Sun, 13 Oct 2002 16:06:53 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9DN6n29007151 for ; Sun, 13 Oct 2002 16:06:50 -0700 (PDT) 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 g9DN6tMq024623 for ; Sun, 13 Oct 2002 16:06:55 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11269 for ; Sun, 13 Oct 2002 16:06:49 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KNNEAJVH4K9LVNL2@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 14 Oct 2002 09:04:41 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8826920023; Mon, 14 Oct 2002 09:04:38 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id A227720018; Mon, 14 Oct 2002 09:04:25 +1000 (EST) Date: Mon, 14 Oct 2002 09:04:25 +1000 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: "Alper E. YEGIN" Cc: Richard Nelson , Thomas Narten , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DA9FBF9.3000805@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200210100233.g9A2X1B03654@cichlid.adsl.duke.edu> <003b01c270c9$9ee6abd0$cdd531d2@co3016429a> <3DA6563B.9070605@eng.monash.edu.au> <010601c27152$45a84db0$3c6015ac@AlperVAIO> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alper, I know it's a risk, especially in Mobile-ip6 case, but the implementation which we're using (mipl) doesn't de-configure existing addresses when it receives an advertisement from a new prefix. The address is not fully deprecated until the advertisement lifetime expires. I'm illustrating what we see if there's no DAD delay, not necessarily what should be done. If we have to do full 2461 DAD in every handover case, even recently visited networks, there's no way VoIP or real time video services will ever be deployed in mobile-ip6 environments, using the current specifications. RS/RA reply is vital in any case, since until the RA is sent out, you don't even know if you're on a different network, where DAD would need to be performed. There's no use doing DAD just because your link layer sends you a message saying your link has just come up. Greg Alper E. YEGIN wrote: > Greg, > > >>I'd just like to indicate that we have seen the delay >>for router advertisement to be a significant delay >>in MIPv6 handovers, since there is no DAD in the case >>where a mobile node moves back to a previously visited >>network. > > > How is that so? Of course the chances of some other > node claiming your node's IP address while it's gone > are even less, but still it is not impossible. So, you can > choose to not use DAD by taking this risk... Is this what > you mean? > > alper > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 04:27:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EBRg29009445; Mon, 14 Oct 2002 04:27:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EBRghH009444; Mon, 14 Oct 2002 04:27:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EBRc29009437 for ; Mon, 14 Oct 2002 04:27:38 -0700 (PDT) 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 g9EBRiMq022556 for ; Mon, 14 Oct 2002 04:27:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21927 for ; Mon, 14 Oct 2002 04:27:38 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14531; Mon, 14 Oct 2002 07:25:27 -0400 (EDT) Message-Id: <200210141125.HAA14531@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-allen-lap-ipv6-00.txt Date: Mon, 14 Oct 2002 07:25:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 for Large Access Providers Author(s) : K. Allen, W. Chen Filename : draft-allen-lap-ipv6-00.txt Pages : 12 Date : 2002-10-11 This document discusses how Large Access Providers (LAP) could use IPv6 to solve current technical challenges. In particular, IPv6Æs large address space and optional header mechanism can be used to provide scalable and manageable broadband Internet access and Virtual Private Network (VPN) services. A new optional header to support forwarding-plane based VPNs is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allen-lap-ipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-allen-lap-ipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-11133732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allen-lap-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-allen-lap-ipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-11133732.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 14 05:46:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ECkV29009807; Mon, 14 Oct 2002 05:46:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ECkVUU009806; Mon, 14 Oct 2002 05:46:31 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ECkQ29009798 for ; Mon, 14 Oct 2002 05:46:27 -0700 (PDT) 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 g9ECkTQ09544; Mon, 14 Oct 2002 14:46:29 +0200 (MEST) Date: Mon, 14 Oct 2002 14:43:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" To: Bob Hinden Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20021011140953.02dc3bb0@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 One high-level comment I have about the document relates to its requirement that the mechanism be the last resort. How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)? One way of using LLMNR is to make *it* be the last resort, but since we can't have two last resorts this is quite problematic. Also, looking at the dns-discovery draft in isolation, it is far from clear to be how one can operationally control this behavior. The document has an implementation note about recommending that there be other mechanisms which take precedence over the well-known addresses, but the document does not require this nor does it specify that a particular mandatory override hence an operator would not be able to control this behavior. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 14 05:53:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ECrT29009906; Mon, 14 Oct 2002 05:53:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ECrS0a009905; Mon, 14 Oct 2002 05:53:28 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ECrP29009898 for ; Mon, 14 Oct 2002 05:53:26 -0700 (PDT) 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 g9ECrVMq002872 for ; Mon, 14 Oct 2002 05:53:31 -0700 (PDT) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22850 for ; Mon, 14 Oct 2002 06:53:24 -0600 (MDT) From: hckwon@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id <4NX8G0VV>; Mon, 14 Oct 2002 21:50:58 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A498683@cms3.etri.re.kr> To: ipng@sunroof.eng.sun.com Subject: [questions] Linux as Gateway is not Working.. (ipv6) Date: Mon, 14 Oct 2002 21:50:57 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27380.571446F0" 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_01C27380.571446F0 Content-Type: text/plain; charset="euc-kr" Help please... We have IPv6 pc-gateway problem.. RH7.2 + Kernel 2.4.18 The Network configurations : eth0 eth1 eth0 eth0 Host1 ------------ GW1 ------------Host2 Host1 eth0 - 3ffe:2e01:1:3::1/64 GW1 eth1 - 3ffe:2e01:1:3::2/64 eth0 - 3ffe:2e01:1:4::1/64 Host2 eth0 - 3ffe:2e01:1:4::3/64 ==== >> Problem : GW1 can not forward packets from Host2 to Host1 and Host1 to Host2 We tries the following.... kernel settings : . ip:advanced router yes . Network packet filtering no . IP:Tunneling no . IPV6 Protocol yes - echo "1" > /proc/sys/net/ipv6/conf/all/forwarding - echo "1" > /proc/sys/net/ipv4/ip_forward ========= GW1 =========== - /etc/sysconfig/network NETWORKING=yes ... GATEWAYDEV=eth1 NETWORKING_IPV6=yes IPV6FORWARDING=yes IPV6_AUTOCONF=no IPV6_ROUTER=yes IPV6_AUTOTUNNEL=no IPV6_TUNNELMODE=IP - /etc/sysconfig/network-scripts/static-routes-ipv6 eth0 3ffe:2e01:1:4::0/64 eth1 2ffe:2e01:1:3::0/64 - /etc/sysconfig/network-scripts/ifcfg-eth0 IPV6INIT="yes" IPV6ADDR=3ffe:2e01:1:4::1/64 IPV6_ROUTER=yes .... - /etc/sysconfig/network-scripts/ifcfg-eth1 IPV6INIT="yes" IPV6ADDR=3ffe:2e01:1:3::2/64 IPV6to4="no" IPV6_ROUTER=yes IPV6_AUTOCONF=no .... ================ Host2 =================== - /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=yes IPV6_AUTOCONF=no IPV6_AUTOTUNNEL=no IPV6_TUNNELMODE=IP - /etc/sysconfig/network-scripts/ifcfg-eth0 BOOTPROTO=none IPV6INIT=yes IPV6ADDR=3ffe:2e01:1:4::3/64 - /etc/sysconfig/network-scripts/static-routes-ipv6 eth0 ::0/0 3ffe:2e01:1:4::1 eth0 3ffe:2e01:1:4::0/64 -------------------------------------------------------- In Host2 : ping6 3ffe:2e01:1:3::1 -> not working ping6 3ffe:2e01:1:3::2 - > not working if we change the prefix (64->48) of host2, then ping6 3ffe:2e01:1:3::1 - > not working ping6 3ffe:2e01:1:3::2 - > working Thanks... ------_=_NextPart_001_01C27380.571446F0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [questions] Linux as Gateway is not Working.. (ipv6)

Help please...
We have IPv6 pc-gateway problem..
 
RH7.2 + Kernel 2.4.18
 
The Network configurations :
 
          = eth0          =           eth1   eth0 =           =          eth0
Host1 ------------ GW1 ------------Host2
 
Host1  eth0 - 3ffe:2e01:1:3::1/64
 
GW1   eth1 - 3ffe:2e01:1:3::2/64
        =           eth0 - = 3ffe:2e01:1:4::1/64
 
Host2  eth0 - 3ffe:2e01:1:4::3/64
 
=3D=3D=3D=3D >> Problem : GW1 can not forward = packets from Host2 to Host1 and Host1 to Host2
 
We tries the following....
 
kernel settings :
 
        . = ip:advanced router    yes
        . Network = packet filtering        no
        . = IP:Tunneling            = no
        . IPV6 = Protocol         =         yes
 
         - = echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
         - = echo "1" > /proc/sys/net/ipv4/ip_forward
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D    GW1 =         = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
-  /etc/sysconfig/network
 
NETWORKING=3Dyes
...
GATEWAYDEV=3Deth1
NETWORKING_IPV6=3Dyes
IPV6FORWARDING=3Dyes
IPV6_AUTOCONF=3Dno
IPV6_ROUTER=3Dyes
 
IPV6_AUTOTUNNEL=3Dno
IPV6_TUNNELMODE=3DIP
 
- = /etc/sysconfig/network-scripts/static-routes-ipv6
 
eth0  3ffe:2e01:1:4::0/64
eth1 2ffe:2e01:1:3::0/64
 
- /etc/sysconfig/network-scripts/ifcfg-eth0
 
IPV6INIT=3D"yes"
IPV6ADDR=3D3ffe:2e01:1:4::1/64
IPV6_ROUTER=3Dyes
....
 
- /etc/sysconfig/network-scripts/ifcfg-eth1
 
IPV6INIT=3D"yes"
IPV6ADDR=3D3ffe:2e01:1:3::2/64
IPV6to4=3D"no"
IPV6_ROUTER=3Dyes
IPV6_AUTOCONF=3Dno
....
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  = Host2   = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
- /etc/sysconfig/network
 
NETWORKING=3Dyes
NETWORKING_IPV6=3Dyes
IPV6_AUTOCONF=3Dno
IPV6_AUTOTUNNEL=3Dno
IPV6_TUNNELMODE=3DIP
 
- /etc/sysconfig/network-scripts/ifcfg-eth0
 
BOOTPROTO=3Dnone
IPV6INIT=3Dyes
IPV6ADDR=3D3ffe:2e01:1:4::3/64
 
- = /etc/sysconfig/network-scripts/static-routes-ipv6
 
eth0    ::0/0   =         =         =         =          = 3ffe:2e01:1:4::1
eth0  3ffe:2e01:1:4::0/64  
 
--------------------------------------------------------=
In Host2  :    ping6 = 3ffe:2e01:1:3::1           =    -> not working
        =         =         =            = ping6 3ffe:2e01:1:3::2       =            -> not = working
 
if we change the prefix (64->48) of host2, then =
        =         =         =            = ping6 3ffe:2e01:1:3::1       =            -> not = working
        =         =         =            = ping6 3ffe:2e01:1:3::2       =            -> = working
 
Thanks...=20

------_=_NextPart_001_01C27380.571446F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 07:46:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EEki29010718; Mon, 14 Oct 2002 07:46:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EEkiaj010717; Mon, 14 Oct 2002 07:46:44 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EEkf29010710 for ; Mon, 14 Oct 2002 07:46:41 -0700 (PDT) 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 g9EEkkMq023364 for ; Mon, 14 Oct 2002 07:46:46 -0700 (PDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26386 for ; Mon, 14 Oct 2002 08:46:41 -0600 (MDT) Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g9EEpF8W006846; Mon, 14 Oct 2002 09:51:15 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g9EEiwW14099; Mon, 14 Oct 2002 09:44:58 -0500 (CDT) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 09:46:34 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D63226BE@trimail2> From: "Chen, Weijing" To: "'ipng@sunroof.eng.sun.com'" , ppvpn@ppvpn.francetelecom.com Subject: FW: I-D ACTION:draft-allen-lap-ipv6-00.txt Date: Mon, 14 Oct 2002 09:46:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C27390.7B87D6E0" 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_000_01C27390.7B87D6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, We would like to bring the attention to this ID announcement. This = draft saw the same "connection-oriented" problem laid out by http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00= .txt . However, the proposal lay out by http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt dealt = more than PPVPN. It dealt with broadband Internet access too. We would = like to seek the interest of ipng group, ppvpn group, and other interesting = party to advance this work. Thanks. -- Weijing Chen -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, October 14, 2002 6:25 AM Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-allen-lap-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 for Large Access Providers Author(s) : K. Allen, W. Chen Filename : draft-allen-lap-ipv6-00.txt Pages : 12 Date : 2002-10-11 =09 This document discusses how Large Access Providers (LAP) could use=20 IPv6 to solve current technical challenges. In particular, IPv6=C6s=20 large address space and optional header mechanism can be used to=20 provide scalable and manageable broadband Internet access and=20 Virtual Private Network (VPN) services. A new optional header to=20 support forwarding-plane based VPNs is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-allen-lap-ipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-allen-lap-ipv6-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C27390.7B87D6E0 Content-Type: message/rfc822 To: Subject: Date: Mon, 14 Oct 2002 09:46:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C27390.7B87D6E0" ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: text/plain ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: application/octet-stream; name="ATT99779.txt" Content-Disposition: attachment; filename="ATT99779.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-11133732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allen-lap-ipv6-00.txt ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-allen-lap-ipv6-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C27390.7B87D6E0-- ------_=_NextPart_000_01C27390.7B87D6E0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 12:48:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EJmZ29013690; Mon, 14 Oct 2002 12:48:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EJmYtv013689; Mon, 14 Oct 2002 12:48:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EJmV29013682 for ; Mon, 14 Oct 2002 12:48:32 -0700 (PDT) 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 g9EJmbMq012367 for ; Mon, 14 Oct 2002 12:48:37 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02075 for ; Mon, 14 Oct 2002 12:48:31 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9EJkXn04460; Mon, 14 Oct 2002 15:46:34 -0400 Message-Id: <200210141946.g9EJkXn04460@cichlid.adsl.duke.edu> To: Jack McCann , jinmei@isl.rdc.toshiba.co.jp cc: ipng@sunroof.eng.sun.com Subject: one more IESG question about RFC 2553bis or 2292bis Date: Mon, 14 Oct 2002 15:46:33 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As Jack has completed his updates to RFC 2553, I've put it back on the IESG for consideration for publication. That prompted the following comment from Bill Fenner. Thoughts on how to proceed? ================ Thomas, Here's an issue that I just discovered today. I can't tell whether it's a 2553bis issue or a 2292bis issue (or both). 2553bis says: The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. [1] is RFC 2460, and doesn't really say anything about sin6_flowinfo per se, but does have the picture of the first 32 bits of the IPv6 packet, and knowing history I know it means that the bottom 28 bits of the sin6_flowinfo field goes after the version. 2292bis says to use the IPV6_TCLASS socket option or ancillary data and doesn't mention sin6_flowinfo. To specify the outgoing traffic class value, just specify the control information as ancillary data for sendmsg() or using setsockopt(). I think having two different ways to specify the traffic class is confusing, especially since 2292bis doesn't refer to the 2553bis way, nor does it say which one is actually used if both are specified. Another problem is that 2460 doesn't say what to put in the sin6_flowinfo (although you can kind of guess), so 2553bis's assertion that 'The contents and interpretation of this member is specified in [1].' is not really true. A possible solution to both of these problems is to remove the traffic class from the sin6_flowinfo, and define the sin6_flowinfo to just contain the 20 bit Flow Label. If the solution is to instead expand 2292bis to talk about the interaction with sin6_flowinfo, then 2553bis should define the actual contents of sin6_flowinfo, not just vaguely refer to 2460. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ would probably be fine. Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 15:07:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EM7n29014639; Mon, 14 Oct 2002 15:07:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EM7nMr014638; Mon, 14 Oct 2002 15:07:49 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EM7j29014628 for ; Mon, 14 Oct 2002 15:07:45 -0700 (PDT) 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 g9EM7oMq019160 for ; Mon, 14 Oct 2002 15:07:50 -0700 (PDT) Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20371 for ; Mon, 14 Oct 2002 16:07:44 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id F160E665 for ; Mon, 14 Oct 2002 18:07:43 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 11FB1238 for ; Mon, 14 Oct 2002 18:37:48 +0000 (GMT) Date: Mon, 14 Oct 2002 11:37:48 -0700 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <3DA8259C.BD1C5CF@nc.rr.com> References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> <20021012035945.39EAC18FA@thrintun.hactrn.net> <3DA8259C.BD1C5CF@nc.rr.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021014183749.11FB1238@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Sat, 12 Oct 2002 09:37:32 -0400, Brian Haberman wrote: > > What if we applied the principles that Erik and I propose in > draft-haberman-ipv6-anycast-rr-00.txt? That would allow for the > resolver to bind an address for the server. If the WG were to go ahead with this DNS discovery mechanism in spite of its flaws, and if the mechanisms you and Erik describe describe prove out and become available[*], then the mechanisms you describe might be a useful partial remedy one of the misfeatures of the DNS discovery mechanism that's currently in WG last call. Sure seems like a lot of work to go to in order to repair one (not all) of the fundamental flaws in a DNS discovery mechanism that's less useful than the pre-existing technology that it's trying to supplant. [*] My understanding is that the mechanisms in your anycast-rr draft are still in the early experimental stage; please correct me if I have that wrong. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 15:07:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EM7l29014636; Mon, 14 Oct 2002 15:07:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EM7k7T014635; Mon, 14 Oct 2002 15:07:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EM7g29014621 for ; Mon, 14 Oct 2002 15:07:43 -0700 (PDT) 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 g9EM7mPG024820 for ; Mon, 14 Oct 2002 15:07:48 -0700 (PDT) Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26070 for ; Mon, 14 Oct 2002 15:07:42 -0700 (PDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id CC96F641 for ; Mon, 14 Oct 2002 18:07:40 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id D91AB20C for ; Mon, 14 Oct 2002 14:00:07 +0000 (GMT) Date: Mon, 14 Oct 2002 07:00:06 -0700 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021014140007.D91AB20C@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An additional (and separate) comment on the DNS discovery draft. Temporarily suspending my disbelief in the mechanism described in this document for purposes of discussion, there's a terminology problem: the draft talks about finding DNS resolvers, which is not really right and which some readers have told me they find confusing. To be clear: this issue is not the fault of the document authors, the underlying DNS terminology is somewhat confusing and frequently misused. It turns out that there is no good short name for the entity that this mechanism is trying to locate, because the DNS terms "name server" and "resolver" really refer to protocol roles rather than to a particular kind of server. This draft is talking about finding an entity that implements both name server and resolver roles, with the name server role acting as a front end for the resolver role under the rules described in the protocol spec for queries with the "recursion desired" bit turned on. The usual way of referring to this kind of entity is as "a name server that offers recursive service", often abbreviated as "a recursive name server" or just "a recursive server". Some implementations have their own terminology for the various possible combinations of the name server and resolver roles, but the terms I'm using here are based on the protocol specification rather than any particular implementation. Thus assuming that the WG decides to go forward with this draft in spite of my objections, for clarity I would recommend that the draft be changed to use the above terminology (use the full phrase the in the introduction to define one of the abbreviated terms, then use the abbreviated term throughout the rest of the document). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 14 15:38:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EMca29014910; Mon, 14 Oct 2002 15:38:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9EMcZjn014909; Mon, 14 Oct 2002 15:38:35 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9EMcW29014902 for ; Mon, 14 Oct 2002 15:38:32 -0700 (PDT) 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 g9EMccMq026933 for ; Mon, 14 Oct 2002 15:38:38 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13614 for ; Mon, 14 Oct 2002 15:38:32 -0700 (PDT) Received: from heavygear ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id PAA08766; Mon, 14 Oct 2002 15:37:37 -0700 (PDT) From: "Qing Li" To: "Erik Nordmark" Cc: "Thomas Narten" , "IPng" Subject: RE: question on next-hop determination Date: Mon, 14 Oct 2002 15:37:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Imagine a case when host1 and host2 are on the same link, but > In the case where host1 and host2 are on two different links, and the default router had a short lifetime then went down unexpectedly. What is the way to differentiating between these 2 cases? Or is it necessary to make such distinction? Because host1 will treat host2 as on-link so it will generate unnecessary traffic on net1, similarly by host2 on net2. This action applies to all those hosts residing on net1 that want to communicate with hosts on net2, and vice versa. Is this an acceptable behavior? Considering the possible number of hosts and applications that may be running, could this be significant enough to have an impact on bandwidth ? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 14 18:19:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F1J129016653; Mon, 14 Oct 2002 18:19:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9F1J0Xv016652; Mon, 14 Oct 2002 18:19:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F1Iu29016642 for ; Mon, 14 Oct 2002 18:18:56 -0700 (PDT) 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 g9F1J1PG009122 for ; Mon, 14 Oct 2002 18:19:01 -0700 (PDT) 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 SAA10868 for ; Mon, 14 Oct 2002 18:18:54 -0700 (PDT) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9F1Ict53973; Tue, 15 Oct 2002 10:18:38 +0900 (JST) Date: Tue, 15 Oct 2002 10:19:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@us.ibm.com, mccann@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: main changes in the new rfc2292bis draft User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200210022029.g92KTnw0002049299@anw.zk3.dec.com> <200210031718.g93HISt0001722042@anw.zk3.dec.com> 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: 99 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm about to submit a new revision of the advanced API (rfc2292bis) draft, mainly in response to comments from you two (thanks, again, for the comments). Most of the changes are trivial or based on consensus in this list. However, I'd like to make an explicit response to some of the comments in order to make it sure that the changes have addressed the comments. If the changes still have some problems, please make a quick (negative) ack. A comment from Thomas: >> int inet6_opt_init(void *extbuf, size_t extlen); >> >> This function returns the number of bytes needed for the empty >> extension header i.e. without any options. > I don't understand this sentence. Does this then always return the > same value? And doesn't an "empty" header require 0 bytes? Or is this > actually "length remaining"? > Actully, the "length" field is weird in subsequent usages to. Is it > really a length, or an offset into the options? Calling it length is > confusing. Is it too late to change this? In the next revision Section 10.1 (for inet6_opt_init()) will have the following paragraph: (Note: since the return value on success is based on a "constant" parameter, i.e. the empty extension header, an implementation may return a constant value. However, this specification does not require the value be constant, and leaves it as implementation dependent. The application should not assume a particular constant value as a successful return value of this function.) Also, "prevlen" parameters in function prototypes for inet6_opt_xxx() will be changed to "offset". Comments from Jack: > - section 11.1 you should cite one or more references upon which > this statement is based: > "Also, path MTU discovery for multicast has severe scalability > limitations and should thus be avoided by default." I could not find a good reference for this sentence, but after re-reading the entire section, I think the wording could have been better without additional references. I'd propose the following paragraphs which replace the paragraph containing the sentence Jack mentioned: [RFC-1981] describes how path MTU discovery works for multicast destinations. From practice in using IPv4 multicast, however, many careless applications that send large multicast packets on the wire have caused implosion of ICMPv4 error messages. The situation can be worse when there is a filtering node that blocks the ICMPv4 messages. Though the filtering issue applies to unicast as well, the impact is much larger in the multicast cases. Thus, applications sending multicast traffic should explicitly enable path MTU discovery only when they understand that the benefit of possibly larger MTU usage outweights the possible impact of MTU discovery for active sources across the delivery tree(s). This default behavior is based on the today's practice with IPv4 multicast and path MTU discovery. The behavior may change in the future once it is found that path MTU discovery effectively works with actual multicast applications and network configurations. > I also want to point out an issue that might be raised if this > API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for > standardization. The functions and macros listed below use a variety > of data types for things that represent a "size", including int, > unsigned int, and size_t. All these items, or at least those of > type size_t, could instead be of type socklen_t. Note that some > of the items identified are for use with msg_controllen and cmsg_len, > which are type socklen_t. In the next revision all size_t types will be changed to "socklen_t" or "int". The new type will be "socklen_t" whenever possible, but the type of function return values will be "int" if it can be a negative integer (as an error result). If such return values are intended to be used as input to other functions, the type of the corresponding arguments will also be "int". For example, the return type of inet6_opt_init() and the 3rd argument of inet6_opt_append() will be left as "int". The return and argument types of CMSG_SPACE and CMSG_LEN will be changed to socklen_t, considering the intended usage, in spite of the following comments from Jack: > Given that CMSG_SPACE and CMSG_LEN were defined in RFC 2292, and > that their definitions have not changed in 2292bis, and that they > do not used size_t, I'd vote for leaving them as is. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 14 19:56:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F2uU29016961; Mon, 14 Oct 2002 19:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9F2uTvs016960; Mon, 14 Oct 2002 19:56:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F2uP29016953 for ; Mon, 14 Oct 2002 19:56:25 -0700 (PDT) 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 g9F2uUMq024154 for ; Mon, 14 Oct 2002 19:56:30 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12397 for ; Mon, 14 Oct 2002 20:56:24 -0600 (MDT) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9F2u7t54391; Tue, 15 Oct 2002 11:56:08 +0900 (JST) Date: Tue, 15 Oct 2002 11:56:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: Jack McCann , ipng@sunroof.eng.sun.com Subject: Re: one more IESG question about RFC 2553bis or 2292bis In-Reply-To: <200210141946.g9EJkXn04460@cichlid.adsl.duke.edu> References: <200210141946.g9EJkXn04460@cichlid.adsl.duke.edu> 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: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 14 Oct 2002 15:46:33 -0400, >>>>> Thomas Narten said: > As Jack has completed his updates to RFC 2553, I've put it back on the > IESG for consideration for publication. That prompted the following > comment from Bill Fenner. > Thoughts on how to proceed? This is a good catch. If I remember correctly, a separate draft (draft-itojun-ipv6-flowlabel-api-01.txt --I don't know if this is the latest one) was issued to clarify the API for flow labels. After some discussions, however, the revise of the draft was suspended, because the protocol usage of flow labels was still unclear. (And, this was the reason why the draft was not incorporated into rfc2292bis.) Thus, I think the best way is - to remove the paragraph of 2553bis in question, and - (if necessary) to clarify the detailed usage of sin6_flowinfo is not defined in 2553bis because the protocol specification of flow labels is still unclear. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 14 19:58:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F2w829016978; Mon, 14 Oct 2002 19:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9F2w7wd016977; Mon, 14 Oct 2002 19:58:07 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F2w429016970 for ; Mon, 14 Oct 2002 19:58:04 -0700 (PDT) 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 g9F2wAMq024339 for ; Mon, 14 Oct 2002 19:58:10 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27201 for ; Mon, 14 Oct 2002 19:58:03 -0700 (PDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 6FFFD146D2; Tue, 15 Oct 2002 12:58:00 +1000 (EST) Date: Tue, 15 Oct 2002 12:58:00 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Subject: Optimistic DAD draft ... Message-ID: <20021015125759.B23137@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day IPng-ers, One of the big issues in getting low-latency handovers working for IPv6 mobility is the long delay involved in completing DAD. One option is to allow the Mobile Node to communicate while the address is still Tentative (optimistically assuming that DAD will succeed), but to adjust its ND / SAA behaviour in order to minimize disruption in case of an address conflict (and maintain correct interoperation with unmodified nodes). We've kicked the idea around a little on mobile-ip, and I've formalized my thoughts into an internet draft, which should get published soon. In the meantime, you can find it at (tentatively titled draft-moore-ipv6-optimistic-dad-00). I'd be interested in your opinions on the draft, and its potential suitability for standards track. cheers, Nick -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 02:13:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F9DA29018223; Tue, 15 Oct 2002 02:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9F9DAXd018222; Tue, 15 Oct 2002 02:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F9D729018215 for ; Tue, 15 Oct 2002 02:13:07 -0700 (PDT) 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 g9F9DDPG015469 for ; Tue, 15 Oct 2002 02:13:13 -0700 (PDT) Received: from wireless.cs.twsu.edu (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03241 for ; Tue, 15 Oct 2002 03:13:07 -0600 (MDT) Received: from localhost ([127.0.0.1]) by basit.cc with esmtp (Exim 4.05) id 17OOQb-0007Bz-00 for ipng@sunroof.eng.sun.com; Sat, 29 Jun 2002 15:02:41 -0500 Date: Sat, 29 Jun 2002 15:02:41 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: ipv6 jumbograms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello I have read the ietf draft on ipv6 jumbograms but i was unable to get why there is a need to send such a large IP packet( > 655.35) , what benefits we can get out of ipv6 jumbograms ? I haven't this discussion in that draft. any help ? thanks -basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 02:20:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F9KR29018277; Tue, 15 Oct 2002 02:20:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9F9KRd4018276; Tue, 15 Oct 2002 02:20:27 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9F9KN29018267 for ; Tue, 15 Oct 2002 02:20:23 -0700 (PDT) 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 g9F9KTMq026031 for ; Tue, 15 Oct 2002 02:20:29 -0700 (PDT) Received: from wireless.cs.twsu.edu (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06755 for ; Tue, 15 Oct 2002 03:20:17 -0600 (MDT) Received: from [127.0.0.1] (helo=localhost) by basit.cc with esmtp (Exim 4.10) id 17mImD-0001fA-00; Tue, 03 Sep 2002 13:51:49 -0500 Date: Tue, 3 Sep 2002 13:51:49 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: Joe Baptista cc: ipng@sunroof.eng.sun.com Subject: Re: I want a pretty IPv6 address to put on my fireplace this xmas 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 have a look at http://www.nextgencollective.net , its a tunnel broker i can give you a /48 ipv6 addr. allocation .. as far as the isp is concerned you just need to be make sure that protocol 41 isn't blocked also for instant help, look in #ngc irc.openprojects.net (for basit) thanks -basit On Tue, 3 Sep 2002, Joe Baptista wrote: > > Hi: > > Some time ago I asked a number of questions concerning IPv6 for an > interview. I want to thank all who participated and helped. I will be > publishing the article here when it's up. > > But I want to go one step further. I want to test IPv6 out for myself. > And so far I have not had much luck finding an allocation. I've visited > the 6bone and contacted some 6bone people about getting an allocation to > test for a future article. they recommended i try 6to4 but i still need a > connection to the 6bone. in any case i would rather connect directly to > the 6bone. am i deluding myself in thinking this can be accomplished? > > my local isp - a major canadian company has no idea what ipv6 is. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 04:05:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FB5d29018761; Tue, 15 Oct 2002 04:05:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FB5dbW018760; Tue, 15 Oct 2002 04:05:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FB5Z29018753 for ; Tue, 15 Oct 2002 04:05:36 -0700 (PDT) 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 g9FB5fPG000825 for ; Tue, 15 Oct 2002 04:05:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28574; Tue, 15 Oct 2002 05:05:33 -0600 (MDT) 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 g9FB4sI00297; Tue, 15 Oct 2002 18:04:57 +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 g9FB4ih16369; Tue, 15 Oct 2002 18:04:46 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Oct 2002 18:04:44 +0700 Message-ID: <16367.1034679884@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 14 Oct 2002 14:43:41 +0200 (CEST) From: Erik Nordmark Message-ID: | How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)? | One way of using LLMNR is to make *it* be the last resort, but since | we can't have two last resorts this is quite problematic. LLMNR isn't really intended to be "last resort" in the same sense. The "well known address" system can only be defended in way at all, if you only ever use it (attempt it) if everything else has totally failed. That is, rather than giving up and saying "network is broken, I can't look up that name", a resolver can try this one last (valiant but probably useless) attempt to get a reply from somewhere. | Also, looking at the dns-discovery draft in isolation, it is far | from clear to be how one can operationally control this behavior. That's not surprising, one cannot, or it would be useless. Or perhaps, more correctly, it's useless anyway, but if there was an easy way to disable it (aside from providing some other mechanism which actually works, which will effectively disable it), it couldn't even hold out the false hope. The real problem about the draft is that it is stealing my address space to allow others to neglect rational configuration. I agree with all Rob Austein said about this as well (certainly including the issue of terminology), with the possible exception of ... Finally, I remain unconvinced that this is a problem that the IPv6 WG ought to be trying to solve at all. Unless a solution emerges from somewhere else, I think this WG does need to work on the problem, as one of the promises of IPv6 is stateless autoconfiguration. And without being able to use DNS names, no matter how configured the box believes it is, it is useless. Some workable solution to this is needed. Personally I don't think this draft is a satisfactory answer. It is more of a "well, we did this, and so the problem can be handled" type answer, just so there is something. But if that's what we really want, just for the IPv6 WG to provide something, and then to assume that a real workable answer comes from elsewhere, then, OK I guess. I know I'll never be running recursive servers on the addresses it specifies (most likely will never be using those addresses at all, but who knows, it would be a good place to stick a server that simply returns a NXDOMAIN reply to every query it receives) but given that people insist on attempting to define what I'm supposed to do with the address space allocated to me to manage, this is no worse than any of the rest of that. 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 Oct 15 04:33:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FBXL29018895; Tue, 15 Oct 2002 04:33:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FBXLEN018894; Tue, 15 Oct 2002 04:33:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FBXC29018876; Tue, 15 Oct 2002 04:33:12 -0700 (PDT) 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 g9FBXHPG004392; Tue, 15 Oct 2002 04:33:18 -0700 (PDT) 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 FAA13880; Tue, 15 Oct 2002 05:33:03 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26501; Tue, 15 Oct 2002 07:30:51 -0400 (EDT) Message-Id: <200210151130.HAA26501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-moore-ipv6-optimistic-dad-00.txt Date: Tue, 15 Oct 2002 07:30:51 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimistic Duplicate Address Detection Author(s) : N. Moore Filename : draft-moore-ipv6-optimistic-dad-00.txt Pages : 9 Date : 2002-10-14 Optimistic DAD is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-moore-ipv6-optimistic-dad-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-moore-ipv6-optimistic-dad-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-14142216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-moore-ipv6-optimistic-dad-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-moore-ipv6-optimistic-dad-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142216.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 04:43:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FBhL29019051; Tue, 15 Oct 2002 04:43:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FBhK2F019050; Tue, 15 Oct 2002 04:43:20 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FBhH29019043 for ; Tue, 15 Oct 2002 04:43:17 -0700 (PDT) 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 g9FBhNMq015052 for ; Tue, 15 Oct 2002 04:43:23 -0700 (PDT) Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28082 for ; Tue, 15 Oct 2002 05:43:17 -0600 (MDT) Received: from mlab.yrp.nttdocomo.co.jp (mlab.yrp.nttdocomo.co.jp [172.20.64.40]) by mail0.yrp.nttdocomo.co.jp (8.11.6/YRPHUB0-8820020412) with ESMTP id g9FBhGf27769 for ; Tue, 15 Oct 2002 20:43:16 +0900 (JST) Received: from ichiro.mlab.yrp.nttdocomo.co.jp ([172.20.67.226]) by mlab.yrp.nttdocomo.co.jp (8.11.6/YRPDOMAIN-8920020214) with ESMTP id g9FBhF308829 for ; Tue, 15 Oct 2002 20:43:15 +0900 (JST) Message-Id: <5.0.2.7.2.20021015202345.04da16c8@mlab.yrp.nttdocomo.co.jp> X-Sender: okajima@mlab.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Tue, 15 Oct 2002 20:42:06 +0900 To: ipng@sunroof.eng.sun.com From: Ichiro Okajima Subject: Tunneling of packets destined for link local address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I would like to know how an IPv6 router processes a tunneling packet in which the destination address of outer packet is a global address of one of interfaces and the destination address of inner packet is link local address such as solicited node multicast address. Is tunneling of packets destined for link local address just prohibited? If it were allowed, does a router decapsulate the inner packet and send it to the interface which the destination address of the outer packet indicates? How about in the case that the destination address of the outer packet is subnet router anycast address? Regards, Ichiro Okajima NTT DoCoMo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 05:02:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FC2c29019229; Tue, 15 Oct 2002 05:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FC2cfG019228; Tue, 15 Oct 2002 05:02:38 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FC2Z29019221 for ; Tue, 15 Oct 2002 05:02:35 -0700 (PDT) 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 g9FC2fMq017797 for ; Tue, 15 Oct 2002 05:02:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26112 for ; Tue, 15 Oct 2002 05:02:34 -0700 (PDT) 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 g9FC1wI03614; Tue, 15 Oct 2002 19:01:58 +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 g9FC1mh16821; Tue, 15 Oct 2002 19:01:48 +0700 (ICT) From: Robert Elz To: Ichiro Okajima cc: ipng@sunroof.eng.sun.com Subject: Re: Tunneling of packets destined for link local address In-Reply-To: <5.0.2.7.2.20021015202345.04da16c8@mlab.yrp.nttdocomo.co.jp> References: <5.0.2.7.2.20021015202345.04da16c8@mlab.yrp.nttdocomo.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Oct 2002 19:01:48 +0700 Message-ID: <16819.1034683308@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Oct 2002 20:42:06 +0900 From: Ichiro Okajima Message-ID: <5.0.2.7.2.20021015202345.04da16c8@mlab.yrp.nttdocomo.co.jp> | Is tunneling of packets destined for link local address just prohibited? Yes, of course, but ... | If it were allowed, does a router decapsulate the inner packet and send | it to the interface which the destination address of the outer packet | indicates? No, the tunnel provides its own virtual interface. The link local address needs to be the one assigned to that virtual interface, or the packet will be discarded. It can't cross over to any other interface (real or otherwise). | How about in the case that the destination address of the outer packet | is subnet router anycast address? That's fine, if the box is a router, configured to answer that address on that interface, then it will reply. 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 Oct 15 05:09:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FC9929019284; Tue, 15 Oct 2002 05:09:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FC99k1019283; Tue, 15 Oct 2002 05:09:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FC9629019276 for ; Tue, 15 Oct 2002 05:09:06 -0700 (PDT) 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 g9FC9BPG008318 for ; Tue, 15 Oct 2002 05:09:11 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28821 for ; Tue, 15 Oct 2002 06:09:05 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9FC8tR01286; Tue, 15 Oct 2002 15:08:55 +0300 Date: Tue, 15 Oct 2002 15:08:55 +0300 (EEST) From: Pekka Savola To: Ichiro Okajima cc: ipng@sunroof.eng.sun.com Subject: Re: Tunneling of packets destined for link local address In-Reply-To: <5.0.2.7.2.20021015202345.04da16c8@mlab.yrp.nttdocomo.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Oct 2002, Ichiro Okajima wrote: > I would like to know how an IPv6 router processes a tunneling packet > in which the destination address of outer packet is a global address > of one of interfaces and the destination address of inner packet > is link local address such as solicited node multicast address. > > Is tunneling of packets destined for link local address just prohibited? No, it's allowed. > If it were allowed, does a router decapsulate the inner packet and send > it to the interface which the destination address of the outer packet > indicates? I believe the answer is "the tunnel pseudo-interface performing decapsulation". Whether that's useful is another story.. > How about in the case that the destination address of the outer packet > is subnet router anycast address? The same. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 06:44:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FDiX29019834; Tue, 15 Oct 2002 06:44:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FDiXKj019833; Tue, 15 Oct 2002 06:44:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FDiT29019826 for ; Tue, 15 Oct 2002 06:44:30 -0700 (PDT) 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 g9FDiZPG022531 for ; Tue, 15 Oct 2002 06:44:35 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27181 for ; Tue, 15 Oct 2002 07:44:29 -0600 (MDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9FDiQbo117944; Tue, 15 Oct 2002 09:44:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9FDiOv5088518; Tue, 15 Oct 2002 09:44:24 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9FDgF122300; Tue, 15 Oct 2002 09:42:15 -0400 Message-Id: <200210151342.g9FDgF122300@rotala.raleigh.ibm.com> To: diffserv@ietf.org cc: ipng@sunroof.eng.sun.com Subject: APIs for diffserv Date: Tue, 15 Oct 2002 09:42:15 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 basic and advanced APIs include placeholders/hooks for specifying the Flow Label on outgoing IPv6 packets. But the way the API is specified, the entire first 32 bits of the IP header can be specified, which includes the Traffic Class field. Many of the details are unspecified, however. Questions: 1) What work has been done with regards to specifying an API for setting the Traffic Class fields? Anything other than the IPv6 APIs? 2) Is it adequiate for the existing IPv6 APIs (basic and advanced) to simply allow the traffic class to be set via the flow label mechanism (without specifying the details much)? 3) What about APIs for IPv4? Aren't they needed too? 4) Or is there an assumption here that endpoint applications setting the traffic class themselves via an API is not particularly interesting or necessary? Have a look at draft-ietf-ipngwg-rfc2553bis-07.txt and draft-ietf-ipngwg-rfc2292bis-07.txt for the details of what has been specified so far. Thoughts of what (if anything more) should be done with APIs for diffserv would be appreciated. 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 Oct 15 11:44:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FIid29022536; Tue, 15 Oct 2002 11:44:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FIicAv022535; Tue, 15 Oct 2002 11:44:38 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FIiZ29022528 for ; Tue, 15 Oct 2002 11:44:35 -0700 (PDT) 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 g9FIifMq025253 for ; Tue, 15 Oct 2002 11:44:41 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27047 for ; Tue, 15 Oct 2002 11:44:36 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 24DE01126; Tue, 15 Oct 2002 11:44:36 -0700 (PDT) Received: from anw.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 1DD721BCF; Tue, 15 Oct 2002 11:44:32 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g9FIiVC0000546512; Tue, 15 Oct 2002 14:44:31 -0400 (EDT) Date: Tue, 15 Oct 2002 14:44:31 -0400 (EDT) From: Jack McCann Message-Id: <200210151844.g9FIiVC0000546512@anw.zk3.dec.com> To: jinmei@isl.rdc.toshiba.co.jp, mccann@zk3.dec.com, narten@us.ibm.com Subject: Re: one more IESG question about RFC 2553bis or 2292bis Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: >As Jack has completed his updates to RFC 2553, I've put it back on the >IESG for consideration for publication. That prompted the following >comment from Bill Fenner. Yes, I mentioned this in my response to the last round of iesg comments on 2553bis: c. The use of sin6_flowinfo is rather underspecified. Of the 32 bits, which ones contain the traffic class and which ones contain the flow label? What's in the other 4 bits? Can I use it to set the traffic class and/or flow label for outbound packets (e.g. on a connect(), sendto() or sendmsg()? What is behavior of this field on accept/recvfrom/recvmsg? What is behavior with TCP? What is interaction with IPV6_TCLASS option from rfc2292bis? I checked the Austin spec, it does not describe the contents of the sin6_flowinfo field, other than this comment beside the field definition: uint32_t sin6_flowinfo IPv6 traffic class and flow information JINMEI Tatuya wrote: >Thus, I think the best way is > >- to remove the paragraph of 2553bis in question, and >- (if necessary) to clarify the detailed usage of sin6_flowinfo is not > defined in 2553bis because the protocol specification of flow labels > is still unclear. I agree with the latter statement, I suggest we treat it as we did the sin6_scope_id field. Change this paragraph: The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. to this: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact use of this field is not currently specified. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 13:21:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKLa29023359; Tue, 15 Oct 2002 13:21:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FKLavd023358; Tue, 15 Oct 2002 13:21:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKLW29023351 for ; Tue, 15 Oct 2002 13:21:32 -0700 (PDT) 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 g9FKLcPG003771 for ; Tue, 15 Oct 2002 13:21:38 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18961 for ; Tue, 15 Oct 2002 13:21:33 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 15 Oct 2002 13:21:32 -0700 Reply-To: From: "Tony Hain" To: "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 13:21:16 -0700 Message-ID: <0c1501c27488$6c367e00$011aa8c0@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.3416 Importance: Normal In-Reply-To: <20021015125759.B23137@dwerryhouse.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9FKLX29023352 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Without having read the draft, it occurs to me that the whole idea of DAD latency impacting hand-offs is a self inflicted problem. From the perspective of 'failure to plan on your part does not constitute an emergency on my part', it would seem the prudent thing for a MN to do is establish DAD for all candidate prefixes well before it is ready to start using them. I realize this creates extra traffic if the node doesn't end up moving, but it also prevents a node from stepping on someone else that was actively using an address. Which is more important, making sure a node can move quickly, or making sure a stationary node is not interrupted??? Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > 'Sharkey' Moore > Sent: Monday, October 14, 2002 7:58 PM > To: ipng@sunroof.eng.sun.com > Subject: Optimistic DAD draft ... > > > G'day IPng-ers, > > One of the big issues in getting low-latency > handovers working for IPv6 mobility is the long delay > involved in completing DAD. > > One option is to allow the Mobile Node to communicate > while the address is still Tentative (optimistically assuming > that DAD will succeed), but to adjust its ND / SAA behaviour > in order to minimize disruption in case of an address > conflict (and maintain correct interoperation with unmodified nodes). > > We've kicked the idea around a little on mobile-ip, > and I've formalized my thoughts into an internet draft, > which should get published soon. In the meantime, you can > find it at > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > I'd be interested in your opinions on the draft, > and its potential suitability for standards track. > > > cheers, > Nick > -- > Nick 'Sharkey' Moore > Research Fellow, CTIE Tel: +61 3 9905 3707 > Monash University, Australia Fax: +61 3 9905 5358 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 15 13:31:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKVm29023538; Tue, 15 Oct 2002 13:31:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FKVm6A023537; Tue, 15 Oct 2002 13:31:48 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKVi29023530 for ; Tue, 15 Oct 2002 13:31:45 -0700 (PDT) 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 g9FKVoMq028273 for ; Tue, 15 Oct 2002 13:31:50 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26076 for ; Tue, 15 Oct 2002 13:31:44 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9FKVVE05526; Tue, 15 Oct 2002 23:31:31 +0300 Date: Tue, 15 Oct 2002 23:31:31 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... In-Reply-To: <0c1501c27488$6c367e00$011aa8c0@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Oct 2002, Tony Hain wrote: > [...] it would seem the prudent thing for a MN to do is > establish DAD for all candidate prefixes well before it is ready to > start using them. [...] Isn't there a problem with how this could be done, as currently specified? One can't perform DAD before being on the link. > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > 'Sharkey' Moore > > Sent: Monday, October 14, 2002 7:58 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Optimistic DAD draft ... > > > > > > G'day IPng-ers, > > > > One of the big issues in getting low-latency > > handovers working for IPv6 mobility is the long delay > > involved in completing DAD. > > > > One option is to allow the Mobile Node to communicate > > while the address is still Tentative (optimistically assuming > > that DAD will succeed), but to adjust its ND / SAA behaviour > > in order to minimize disruption in case of an address > > conflict (and maintain correct interoperation with unmodified nodes). > > > > We've kicked the idea around a little on mobile-ip, > > and I've formalized my thoughts into an internet draft, > > which should get published soon. In the meantime, you can > > find it at > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > I'd be interested in your opinions on the draft, > > and its potential suitability for standards track. > > > > > > cheers, > > Nick > > -- > > Nick 'Sharkey' Moore > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > Monash University, Australia Fax: +61 3 9905 5358 > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 13:35:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKZn29023606; Tue, 15 Oct 2002 13:35:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FKZn39023605; Tue, 15 Oct 2002 13:35:49 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKZj29023595 for ; Tue, 15 Oct 2002 13:35:45 -0700 (PDT) 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 g9FKZpMq029526 for ; Tue, 15 Oct 2002 13:35:51 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28893 for ; Tue, 15 Oct 2002 13:35:46 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 15 Oct 2002 13:35:48 -0700 Reply-To: From: "Tony Hain" To: "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 13:35:32 -0700 Message-ID: <0c2c01c2748a$694eb570$011aa8c0@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.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9FKZk29023597 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk True, but the term 'hand-off' implies a make-before-break process, else the MN is just establishing itself on a new link. Given it has the opportunity to be aware of multiple links, it can decide when to switch. I am arguing that it complete DAD 'before' it makes that decision, not after. Tony > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, October 15, 2002 1:32 PM > To: Tony Hain > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: RE: Optimistic DAD draft ... > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > [...] it would seem the prudent thing for a MN to do is > establish DAD > > for all candidate prefixes well before it is ready to start using > > them. [...] > > Isn't there a problem with how this could be done, as > currently specified? > > One can't perform DAD before being on the link. > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > 'Sharkey' Moore > > > Sent: Monday, October 14, 2002 7:58 PM > > > To: ipng@sunroof.eng.sun.com > > > Subject: Optimistic DAD draft ... > > > > > > > > > G'day IPng-ers, > > > > > > One of the big issues in getting low-latency > > > handovers working for IPv6 mobility is the long delay involved in > > > completing DAD. > > > > > > One option is to allow the Mobile Node to communicate > > > while the address is still Tentative (optimistically assuming > > > that DAD will succeed), but to adjust its ND / SAA behaviour > > > in order to minimize disruption in case of an address > > > conflict (and maintain correct interoperation with > unmodified nodes). > > > > > > We've kicked the idea around a little on mobile-ip, > > > and I've formalized my thoughts into an internet draft, > which should > > > get published soon. In the meantime, you can find it at > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > I'd be interested in your opinions on the draft, and its > > > potential suitability for standards track. > > > > > > > > > cheers, > > > Nick > > > -- > > > Nick 'Sharkey' Moore > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 13:36:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKaf29023629; Tue, 15 Oct 2002 13:36:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FKafBA023628; Tue, 15 Oct 2002 13:36:41 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FKaa29023618 for ; Tue, 15 Oct 2002 13:36:36 -0700 (PDT) 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 g9FKagMq029835 for ; Tue, 15 Oct 2002 13:36:42 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08051 for ; Tue, 15 Oct 2002 14:36:35 -0600 (MDT) 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 g9FKaOtt023094; Tue, 15 Oct 2002 22:36:24 +0200 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 g9FKaNcH059548; Tue, 15 Oct 2002 22:36:24 +0200 Received: from gsine05.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39514 from ; Tue, 15 Oct 2002 22:36:16 +0200 Message-Id: <3DAC7C39.A17C7C3C@hursley.ibm.com> Date: Tue, 15 Oct 2002 22:36:09 +0200 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: diffserv@ietf.org, ipng@sunroof.eng.sun.com, Jun-ichiro itojun Hagino Subject: Re: [Diffserv] APIs for diffserv References: <200210151342.g9FDgF122300@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > The IPv6 basic and advanced APIs include placeholders/hooks for > specifying the Flow Label on outgoing IPv6 packets. But the way the > API is specified, the entire first 32 bits of the IP header can be > specified, which includes the Traffic Class field. Many of the details > are unspecified, however. > > Questions: > > 1) What work has been done with regards to specifying an API for > setting the Traffic Class fields? Anything other than the IPv6 > APIs? There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001). itojun may want to comment. > > 2) Is it adequiate for the existing IPv6 APIs (basic and advanced) > to simply allow the traffic class to be set via the flow label > mechanism (without specifying the details much)? It needs to be possible to set the 6 bits of the DSCP independently of either the flow label or the ECN bits. Ditto the flow label. If the proposed APIs can't do that, they are inadequate. > > 3) What about APIs for IPv4? Aren't they needed too? I thought that you could set the TOS byte in the v4 API. Again, you have to avoid messing up the ECN bits, but I would expect the TCP/IP stack to take over those bits. > > 4) Or is there an assumption here that endpoint applications setting > the traffic class themselves via an API is not particularly > interesting or necessary? It's been debated, but in the general case it is desirable. The DSCP bits may be set within the stack by a QOS manager, or downstream by a router, but apps should have the ability in principle. The flow label may be set within the stack, or in principle by the app. Brian > > Have a look at > > draft-ietf-ipngwg-rfc2553bis-07.txt and > draft-ietf-ipngwg-rfc2292bis-07.txt > > for the details of what has been specified so far. > > Thoughts of what (if anything more) should be done with APIs for > diffserv would be appreciated. > > Thomas > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 14:04:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FL4r29023974; Tue, 15 Oct 2002 14:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FL4qWh023973; Tue, 15 Oct 2002 14:04:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FL4n29023966 for ; Tue, 15 Oct 2002 14:04:49 -0700 (PDT) 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 g9FL4tMq008275 for ; Tue, 15 Oct 2002 14:04:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07320 for ; Tue, 15 Oct 2002 15:04:49 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9FL4ed05865; Wed, 16 Oct 2002 00:04:41 +0300 Date: Wed, 16 Oct 2002 00:04:40 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Thomas Narten , , , Jun-ichiro itojun Hagino Subject: Re: [Diffserv] APIs for diffserv In-Reply-To: <3DAC7C39.A17C7C3C@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 On Tue, 15 Oct 2002, Brian E Carpenter wrote: > Thomas Narten wrote: > > > > The IPv6 basic and advanced APIs include placeholders/hooks for > > specifying the Flow Label on outgoing IPv6 packets. But the way the > > API is specified, the entire first 32 bits of the IP header can be > > specified, which includes the Traffic Class field. Many of the details > > are unspecified, however. > > > > Questions: > > > > 1) What work has been done with regards to specifying an API for > > setting the Traffic Class fields? Anything other than the IPv6 > > APIs? > > There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001). > itojun may want to comment. [...] And also draft-itojun-ipv6-tclass-api-03.txt (July 2001): ftp://ftp.itojun.org/pub/paper/draft-itojun-ipv6-tclass-api-03.txt -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 14:47:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FLl829024149; Tue, 15 Oct 2002 14:47:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FLl88r024148; Tue, 15 Oct 2002 14:47:08 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FLl429024141 for ; Tue, 15 Oct 2002 14:47:04 -0700 (PDT) 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 g9FLl9Mq019912 for ; Tue, 15 Oct 2002 14:47:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05013 for ; Tue, 15 Oct 2002 15:47:04 -0600 (MDT) 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 OAA11726; Tue, 15 Oct 2002 14:47:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9FLkuw19232; Tue, 15 Oct 2002 14:46:56 -0700 X-mProtect: <200210152146> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsk9rJM; Tue, 15 Oct 2002 14:46:54 PDT Message-ID: <3DAC8CCF.4E20251D@iprg.nokia.com> Date: Tue, 15 Oct 2002 14:46:55 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Pekka Savola'" , "'Nick 'Sharkey' Moore'" , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... References: <0c2c01c2748a$694eb570$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Tony, It is possible to have nice handoffs even with break-before-make, as long as "break" is not too lengthy. If the determination about the destination network is available in time, completing DAD before switching is a good idea -- whether or not the handoff is "break-before-make". This is under discussion within the seamoby working group. We have a draft about it, and an optimistic DAD scheme. When my head rises more than an millimeter above water, I'll read the draft in the Subject: line (glub, glub). Regards, Charlie P. Tony Hain wrote: > > True, but the term 'hand-off' implies a make-before-break process, else > the MN is just establishing itself on a new link. Given it has the > opportunity to be aware of multiple links, it can decide when to switch. > I am arguing that it complete DAD 'before' it makes that decision, not > after. > > Tony > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Tuesday, October 15, 2002 1:32 PM > > To: Tony Hain > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > Subject: RE: Optimistic DAD draft ... > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > [...] it would seem the prudent thing for a MN to do is > > establish DAD > > > for all candidate prefixes well before it is ready to start using > > > them. [...] > > > > Isn't there a problem with how this could be done, as > > currently specified? > > > > One can't perform DAD before being on the link. > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > 'Sharkey' Moore > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > To: ipng@sunroof.eng.sun.com > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > One of the big issues in getting low-latency > > > > handovers working for IPv6 mobility is the long delay involved in > > > > completing DAD. > > > > > > > > One option is to allow the Mobile Node to communicate > > > > while the address is still Tentative (optimistically assuming > > > > that DAD will succeed), but to adjust its ND / SAA behaviour > > > > in order to minimize disruption in case of an address > > > > conflict (and maintain correct interoperation with > > unmodified nodes). > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > and I've formalized my thoughts into an internet draft, > > which should > > > > get published soon. In the meantime, you can find it at > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > I'd be interested in your opinions on the draft, and its > > > > potential suitability for standards track. > > > > > > > > > > > > cheers, > > > > Nick > > > > -- > > > > Nick 'Sharkey' Moore > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 > > > -------------------------------------------------------------------- > > > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 15:08:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FM8F29024418; Tue, 15 Oct 2002 15:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FM8FQU024417; Tue, 15 Oct 2002 15:08:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FM8C29024409 for ; Tue, 15 Oct 2002 15:08:12 -0700 (PDT) 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 g9FM8HPG006095 for ; Tue, 15 Oct 2002 15:08:18 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19130 for ; Tue, 15 Oct 2002 16:08:11 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 129B3146D5; Wed, 16 Oct 2002 08:08:03 +1000 (EST) Date: Wed, 16 Oct 2002 08:05:31 +1000 From: "Nick 'Sharkey' Moore" To: Tony Hain Subject: Re: Optimistic DAD draft ... Message-ID: <20021016080529.A28692@dwerryhouse.com.au> References: <20021015125759.B23137@dwerryhouse.com.au> <0c1501c27488$6c367e00$011aa8c0@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0c1501c27488$6c367e00$011aa8c0@eagleswings>; from alh-ietf@tndh.net on Tue, Oct 15, 2002 at 01:21:16PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 15, 2002 at 01:21:16PM -0700, Tony Hain wrote: > Without having read the draft, it occurs to me that the whole idea of > DAD latency impacting hand-offs is a self inflicted problem. From the > perspective of 'failure to plan on your part does not constitute an > emergency on my part', it would seem the prudent thing for a MN to do is > establish DAD for all candidate prefixes well before it is ready to > start using them. Absolutely. If only more link-layers made this possible! Unfortunately, in practice, MNs often move unexpectedly due to the vagaries of RF propagation. > Which is more > important, making sure a node can move quickly, or making sure a > stationary node is not interrupted??? The draft attempts to address this, by making sure that the Optimistic MN will not interrupt established connections even in the case of collision. cheers, -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 15:13:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMDq29024510; Tue, 15 Oct 2002 15:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMDqJR024509; Tue, 15 Oct 2002 15:13:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMDm29024498 for ; Tue, 15 Oct 2002 15:13:49 -0700 (PDT) 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 g9FMDsMq028171 for ; Tue, 15 Oct 2002 15:13:54 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12991 for ; Tue, 15 Oct 2002 16:13:49 -0600 (MDT) Message-ID: <038d01c27497$eec951d0$426015ac@AlperVAIO> From: "Alper E. YEGIN" To: , "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , References: <0c2c01c2748a$694eb570$011aa8c0@eagleswings> Subject: Re: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 15:11:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, > True, but the term 'hand-off' implies a make-before-break process, else > the MN is just establishing itself on a new link. Given it has the > opportunity to be aware of multiple links, it can decide when to switch. > I am arguing that it complete DAD 'before' it makes that decision, not > after. I don't think we can consider all "handoffs" as 'make-before-break'. There exists some link-layer technologies that allow this, but not all have such capability. Completing DAD before handover requires either movement anticipation or make-before-break, both of which are not widely applicable. Therefore solving DAD latency for general case is a valid approach, imo. alper > > Tony > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Tuesday, October 15, 2002 1:32 PM > > To: Tony Hain > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > Subject: RE: Optimistic DAD draft ... > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > [...] it would seem the prudent thing for a MN to do is > > establish DAD > > > for all candidate prefixes well before it is ready to start using > > > them. [...] > > > > Isn't there a problem with how this could be done, as > > currently specified? > > > > One can't perform DAD before being on the link. > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > 'Sharkey' Moore > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > To: ipng@sunroof.eng.sun.com > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > One of the big issues in getting low-latency > > > > handovers working for IPv6 mobility is the long delay involved in > > > > completing DAD. > > > > > > > > One option is to allow the Mobile Node to communicate > > > > while the address is still Tentative (optimistically assuming > > > > that DAD will succeed), but to adjust its ND / SAA behaviour > > > > in order to minimize disruption in case of an address > > > > conflict (and maintain correct interoperation with > > unmodified nodes). > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > and I've formalized my thoughts into an internet draft, > > which should > > > > get published soon. In the meantime, you can find it at > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > I'd be interested in your opinions on the draft, and its > > > > potential suitability for standards track. > > > > > > > > > > > > cheers, > > > > Nick > > > > -- > > > > Nick 'Sharkey' Moore > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 > > > -------------------------------------------------------------------- > > > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 15:18:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMIU29024592; Tue, 15 Oct 2002 15:18:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMIU0d024591; Tue, 15 Oct 2002 15:18:30 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMIQ29024581 for ; Tue, 15 Oct 2002 15:18:26 -0700 (PDT) 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 g9FMIWMq029603 for ; Tue, 15 Oct 2002 15:18:32 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24706 for ; Tue, 15 Oct 2002 16:18:25 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id BB70C146D2; Wed, 16 Oct 2002 08:18:18 +1000 (EST) Date: Wed, 16 Oct 2002 08:18:18 +1000 From: "Nick 'Sharkey' Moore" To: "Charles E. Perkins" Cc: alh-ietf@tndh.net, "'Pekka Savola'" , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021016081816.B28692@dwerryhouse.com.au> References: <0c2c01c2748a$694eb570$011aa8c0@eagleswings> <3DAC8CCF.4E20251D@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DAC8CCF.4E20251D@iprg.nokia.com>; from charliep@iprg.nokia.com on Tue, Oct 15, 2002 at 02:46:55PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 15, 2002 at 02:46:55PM -0700, Charles E. Perkins wrote: > > It is possible to have nice handoffs even with > break-before-make, as long as "break" is not > too lengthy. If the determination about the > destination network is available in time, completing > DAD before switching is a good idea -- whether or > not the handoff is "break-before-make". Yep ... the mobileip stuff deals with this with a kind of "Neighbour Discovery by Proxy" ... I'll obviously have to come over and have a look at what seamoby is up to as well! > When my head rises more than an millimeter > above water, I'll read the draft in the Subject: line > (glub, glub). :-) It's a short one, honest! No snorkel required ... -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 15:18:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMIq29024605; Tue, 15 Oct 2002 15:18:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMIpe3024604; Tue, 15 Oct 2002 15:18:51 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMIl29024597 for ; Tue, 15 Oct 2002 15:18:47 -0700 (PDT) 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 g9FMIrMq029697 for ; Tue, 15 Oct 2002 15:18:53 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08968 for ; Tue, 15 Oct 2002 15:18:47 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 15 Oct 2002 15:18:50 -0700 Reply-To: From: "Tony Hain" To: "'Charles E. Perkins'" Cc: "'Pekka Savola'" , "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 15:18:34 -0700 Message-ID: <0c3301c27498$cda5ee90$011aa8c0@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.3416 Importance: Normal In-Reply-To: <3DAC8CCF.4E20251D@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9FMIl29024598 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inline > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Charles > E. Perkins > Sent: Tuesday, October 15, 2002 2:47 PM > To: alh-ietf@tndh.net > Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > Hello Tony, > > It is possible to have nice handoffs even with > break-before-make, as long as "break" is not > too lengthy. It seems like this would be a bigger latency concern than DAD. > If the determination about the > destination network is available in time, completing > DAD before switching is a good idea -- whether or > not the handoff is "break-before-make". Maybe I just don't understand the technology well enough, but I from my limited perspective it would seem that the current GGSN would know which radio system the MN was attached to, and therefore could figure out the candidate set of destinations for a hand-off. That list could be forwarded to the MN, so personal policy and signal strength could be applied to sort the list to come up with the best candidates. With that an out of band predictive DAD could be done. This would make much more sense than moving, stepping on an existing node, then backing off. It seems that a little bit of overhead traffic is better than dropping 2 connections. > > This is under discussion within the seamoby working > group. We have a draft about it, and an optimistic > DAD scheme. When my head rises more than an millimeter > above water, I'll read the draft in the Subject: line > (glub, glub). > > Regards, > Charlie P. > > > Tony Hain wrote: > > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can > decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to > start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as currently > > > specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: ipng@sunroof.eng.sun.com > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > handovers working > > > > > for IPv6 mobility is the long delay involved in > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate > while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour > in order to > > > > > minimize disruption in case of an address conflict > (and maintain > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > and I've > > > > > formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the > draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home 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 > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 15:24:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMOU29024721; Tue, 15 Oct 2002 15:24:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMOUV3024720; Tue, 15 Oct 2002 15:24:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMOQ29024713 for ; Tue, 15 Oct 2002 15:24:26 -0700 (PDT) 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 g9FMOWPG010936 for ; Tue, 15 Oct 2002 15:24:32 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28118 for ; Tue, 15 Oct 2002 15:24:26 -0700 (PDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 7E87F146D2; Wed, 16 Oct 2002 08:24:19 +1000 (EST) Date: Wed, 16 Oct 2002 08:24:18 +1000 From: "Nick 'Sharkey' Moore" To: Tony Hain Cc: "'Charles E. Perkins'" , "'Pekka Savola'" , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021016082417.C28692@dwerryhouse.com.au> References: <3DAC8CCF.4E20251D@iprg.nokia.com> <0c3301c27498$cda5ee90$011aa8c0@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0c3301c27498$cda5ee90$011aa8c0@eagleswings>; from alh-ietf@tndh.net on Tue, Oct 15, 2002 at 03:18:34PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 15, 2002 at 03:18:34PM -0700, Tony Hain wrote: > > It seems like this would be a bigger latency concern than DAD. 1000ms is a long time by anyone's standards! > Maybe I just don't understand the technology well enough, but I from my > limited perspective it would seem that the current GGSN would know which > radio system the MN was attached to, and therefore could figure out the > candidate set of destinations for a hand-off. If only the networks we are experimenting with were so civilized! There's a lot of interest in getting MIPv6 working on 802.11 networks though ... -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 15:27:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMRC29024769; Tue, 15 Oct 2002 15:27:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMRCKE024768; Tue, 15 Oct 2002 15:27:12 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMR929024761 for ; Tue, 15 Oct 2002 15:27:09 -0700 (PDT) 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 g9FMRFMq002048 for ; Tue, 15 Oct 2002 15:27:15 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14144 for ; Tue, 15 Oct 2002 15:27:09 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 15 Oct 2002 15:27:12 -0700 Reply-To: From: "Tony Hain" To: "'Alper E. YEGIN'" , "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 15:26:55 -0700 Message-ID: <0c3401c27499$f8bba2e0$011aa8c0@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.3416 Importance: Normal In-Reply-To: <038d01c27497$eec951d0$426015ac@AlperVAIO> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9FMR929024762 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inline > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 3:12 PM > To: alh-ietf@tndh.net; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > > Hi Tony, > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can > decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > I don't think we can consider all "handoffs" as > 'make-before-break'. There exists some link-layer > technologies that allow this, but not all have such capability. Then DAD latency should be the least of the concerns. > > Completing DAD before handover requires either movement > anticipation or make-before-break, both of which are not > widely applicable. Therefore solving DAD latency for general > case is a valid approach, imo. My argument is that all MNs anticipate movement, and establish DAD before they really make the move. Yes this will generate some overhead if the node doesn't move, but that is a minor cost in the grand scheme of things. Tony > > alper > > > > > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to > start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as > > > currently specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: ipng@sunroof.eng.sun.com > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > > > > > handovers working for IPv6 mobility is the long delay > involved > > > > > in > > > > > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate > while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour > in order to > > > > > minimize disruption in case of an address conflict > (and maintain > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > > and I've formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the > draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home 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 > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 15:42:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMgT29024989; Tue, 15 Oct 2002 15:42:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMgToq024988; Tue, 15 Oct 2002 15:42:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMgQ29024981 for ; Tue, 15 Oct 2002 15:42:26 -0700 (PDT) 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 g9FMgVMq005957 for ; Tue, 15 Oct 2002 15:42:31 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00099 for ; Tue, 15 Oct 2002 16:42:26 -0600 (MDT) Message-ID: <03cd01c2749b$d8fb3590$146015ac@T23KEMPF> From: "James Kempf" To: "Brett Pentland" , "Thomas Narten" Cc: References: <200210110110.g9B1AZ804398@cichlid.adsl.duke.edu> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 15 Oct 2002 15:40:19 -0700 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 Thomas, > Seems to me then that this document is a bit narrowly scoped and may > even miss the point. Don't we need to look at the overall problem and > then see what can be done to address the overall problem adequately? > In general, I don't know that its all that useful to focus on a narrow > part of a bigger problem unless the bigger problem is sufficiently > understood that the point solution is understood to be an important > and useful component of it. How do we know that this change will make > any significant difference in practice given the general problem? > You are right that this document is fairly narrowly scoped. To solve the full problem, it requires other parts of the ND process, specifically DAD, to be accelerated as well. Additionally, as was brought up on the list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As was also brought up on the list, this can lead to congestion when mobile nodes move in concert, or when an access point crashes. The FMIPv6 work is certainly a more comprehensive solution, however, the currently understanding of how FMIPv6 would work together with 802.11 is not encouraging. There is, of course, an argument about how much the IETF should modify its specifications to be implementable on a specific link layer. However, for 802.11 to work well with FMIP, there would either need to be a major change in the current firmware implementations for anticipated handover, or an additional protocol would be needed between the AP and the AR for conveying the reassociation link up trigger to the AR, or some special kind of security association would be required between the old AR and the MN in order to do unsolicited FBU signaling from the AR to the MN. The IETF can do some work on the last two of these but the first one is entirely controlled by the IEEE and, worse, by card manufacturers who may or may not implement given that IEEE has no standard. So the deployment alternative with ND as defined in RFC 2461 and the base FMIPv6 document if one wants faster 802.11 handovers is to set MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. Near term, this is likely to be what people do. With this deployment, not only could the above two problems with congestion occur, but the router is now subject to DoS attacks. The advantage of the proposal in draft-khalil-ipng-fastra-00.txt is that the authors believe it would reduce the potential for DoS attacks. Whether or not this is enough of an improvement over the RS reply algorithm as defined by RFC 2461 to standardize, is something for WG and the IESG to decide. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 15:45:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMix29025028; Tue, 15 Oct 2002 15:44:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMix1k025027; Tue, 15 Oct 2002 15:44:59 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMit29025017 for ; Tue, 15 Oct 2002 15:44:56 -0700 (PDT) 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 g9FMj1Mq006585 for ; Tue, 15 Oct 2002 15:45:01 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15178 for ; Tue, 15 Oct 2002 16:44:56 -0600 (MDT) Message-ID: <03e801c2749c$482fd650$426015ac@AlperVAIO> From: "Alper E. YEGIN" To: , "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , References: <0c3401c27499$f8bba2e0$011aa8c0@eagleswings> Subject: Re: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 15:43:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > True, but the term 'hand-off' implies a make-before-break process, > > > else the MN is just establishing itself on a new link. Given it has > > > the opportunity to be aware of multiple links, it can > > decide when to > > > switch. I am arguing that it complete DAD 'before' it makes that > > > decision, not after. > > > > I don't think we can consider all "handoffs" as > > 'make-before-break'. There exists some link-layer > > technologies that allow this, but not all have such capability. > > Then DAD latency should be the least of the concerns. Not really. For example 802.11b (link-layer) handover can take something like 200ms, and DAD would take 1sec on that link. People are already working on shrinking link-layer handover latency, and some should do the same for DAD as well. > > > > > Completing DAD before handover requires either movement > > anticipation or make-before-break, both of which are not > > widely applicable. Therefore solving DAD latency for general > > case is a valid approach, imo. > > My argument is that all MNs anticipate movement, and establish DAD > before they really make the move. Yes this will generate some overhead > if the node doesn't move, but that is a minor cost in the grand scheme > of things. We cannot assume all MNs can "anticipate movement". Not all link-layers have this capability. alper > > Tony > > > > > alper > > > > > > > > > > > > > > Tony > > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > > To: Tony Hain > > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > > [...] it would seem the prudent thing for a MN to do is > > > > establish DAD > > > > > for all candidate prefixes well before it is ready to > > start using > > > > > them. [...] > > > > > > > > Isn't there a problem with how this could be done, as > > > > currently specified? > > > > > > > > One can't perform DAD before being on the link. > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > > 'Sharkey' Moore > > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > > To: ipng@sunroof.eng.sun.com > > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > > > One of the big issues in getting low-latency > > > > > > handovers working for IPv6 mobility is the long delay > > involved > > > > > > in > > > > > > completing DAD. > > > > > > > > > > > > One option is to allow the Mobile Node to communicate > > while the > > > > > > address is still Tentative (optimistically assuming that DAD > > > > > > will succeed), but to adjust its ND / SAA behaviour > > in order to > > > > > > minimize disruption in case of an address conflict > > (and maintain > > > > > > correct interoperation with > > > > unmodified nodes). > > > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > > > and I've formalized my thoughts into an internet draft, > > > > which should > > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > > > I'd be interested in your opinions on the > > draft, and its > > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > > > > cheers, > > > > > > Nick > > > > > > -- > > > > > > Nick 'Sharkey' Moore > > > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > IETF IPng Working Group Mailing List > > > > > > IPng Home 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 > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > -- > > > > Pekka Savola "Tell me of difficulties surmounted, > > > > Netcore Oy not those you stumble over and fall" > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 15:51:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMpx29025143; Tue, 15 Oct 2002 15:51:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FMpwqk025142; Tue, 15 Oct 2002 15:51:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FMps29025135 for ; Tue, 15 Oct 2002 15:51:54 -0700 (PDT) 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 g9FMq0PG017793 for ; Tue, 15 Oct 2002 15:52:00 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19305 for ; Tue, 15 Oct 2002 16:51:54 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H41000JHOUHDC@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 15 Oct 2002 16:51:54 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4100A6LOUGRK@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 15 Oct 2002 16:51:53 -0600 (MDT) Date: Tue, 15 Oct 2002 15:50:55 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" To: Erik Nordmark Cc: Bob Hinden , ipng@sunroof.eng.sun.com Message-id: <3DAC9BCF.8050700@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/20020719 Netscape/7.0 References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: >One high-level comment I have about the document relates to its >requirement that the mechanism be the last resort. > >How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)? >One way of using LLMNR is to make *it* be the last resort, but since >we can't have two last resorts this is quite problematic. > Those are two different things. dns-resolver discovery is to be used to locate a DNS resolver/server in last resort when no other information for finding this server is available. LLMNR (at least to my understanding) is to be used in last resort when the information had not been found in the DNS maps (meaning you already have found a DNS server/resolver). >Also, looking at the dns-discovery draft in isolation, it is far >from clear to be how one can operationally control this behavior. >The document has an implementation note about recommending that there >be other mechanisms which take precedence over the well-known addresses, >but the document does not require this nor does it specify that a particular >mandatory override hence an operator would not be able to control this >behavior. > I thought that the IETF was in the business of specifying protocols, not how people should implement them nor how people should use them. The best we can do here is to providing guidelines like "use it only under those circumstances if you don't want to get hurt" - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 16:00:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FN0K29025276; Tue, 15 Oct 2002 16:00:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FN0KAp025275; Tue, 15 Oct 2002 16:00:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FN0G29025268 for ; Tue, 15 Oct 2002 16:00:16 -0700 (PDT) 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 g9FN0JPG019706 for ; Tue, 15 Oct 2002 16:00:19 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09568 for ; Tue, 15 Oct 2002 17:00:14 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H41001O5P8C0V@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 15 Oct 2002 17:00:13 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4100A1LP8CX6@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 15 Oct 2002 17:00:12 -0600 (MDT) Date: Tue, 15 Oct 2002 15:59:14 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" To: Rob Austein Cc: ipng@sunroof.eng.sun.com Message-id: <3DAC9DC2.8020208@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/20020719 Netscape/7.0 References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> <20021012035945.39EAC18FA@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob Austein wrote: >My main objection was and remains that this mechanism, if used, moves >state away from the endpoints and into the network in a way that >cripples the resolver's ability to keep track of which of the name >servers it is using are performing properly, since the binding between >any particular well-known-address and the name server behind it might >change at any time and since there is no mechanism by which the >resolver can find out that such a change has taken place. > But isn't this already the case today, at least with some root servers operating with an anycast address? See RFC3258. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 16:21:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FNL529025502; Tue, 15 Oct 2002 16:21:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9FNL5he025501; Tue, 15 Oct 2002 16:21:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9FNL029025494 for ; Tue, 15 Oct 2002 16:21:00 -0700 (PDT) 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 g9FNL6PG024969 for ; Tue, 15 Oct 2002 16:21:06 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16866 for ; Tue, 15 Oct 2002 16:21:01 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 15 Oct 2002 16:21:03 -0700 Reply-To: From: "Tony Hain" To: "'Alper E. YEGIN'" , "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , Subject: RE: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 16:20:46 -0700 Message-ID: <0c3b01c274a1$7eca2990$011aa8c0@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.3416 Importance: Normal In-Reply-To: <03e801c2749c$482fd650$426015ac@AlperVAIO> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9FNL129025495 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper E. YEGIN wrote: > ... > We cannot assume all MNs can "anticipate movement". Not all > link-layers > have this capability. A MN 'can anticipate movement' because that is what it does by definition. What it may not be able to figure out is the candidate list of where it may end up. The fact that some link layer implementations have chosen not to expose knowledge of potential alternatives is possibly due to a lack of requirements to do so. I know the 802.11 implementation I am using is fully aware of the candidate set of layer 1 associations, though it doesn't attempt to bind the IP stack until I select one. It would be easy for it to bind IP to all, but prioritize to the selected one until it was out of range. If it did so, all possible destinations could have run a full DAD in the background, well in advance of the move. Even if the MN implementation chose not to associate with all possible layer 1 neighbors, the ones it does have an association with will also be able to hear a partial list of the candidate set, and could provide that to the MN if the implementation provided a path from the layer 1 receiver to a control plane process. It is true that a standards effort can not assume that all implementations will provide a full spectrum of capability, but it is also true that it MUST NOT assume that ignoring a collision avoidance system will not really do any harm. If people want to be mobile, but a specific link-layer doesn't provide the tools to make that work correctly without problems, the link-layer will fade from the market place. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 18:28:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G1SD29025883; Tue, 15 Oct 2002 18:28:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G1SDSM025882; Tue, 15 Oct 2002 18:28:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G1S929025875 for ; Tue, 15 Oct 2002 18:28:09 -0700 (PDT) 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 g9G1SDPG022626 for ; Tue, 15 Oct 2002 18:28:13 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14020 for ; Tue, 15 Oct 2002 19:28:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 96DC14B22; Wed, 16 Oct 2002 10:28:03 +0900 (JST) To: Brian E Carpenter Cc: Thomas Narten , diffserv@ietf.org, ipng@sunroof.eng.sun.com In-reply-to: brian's message of Tue, 15 Oct 2002 22:36:09 +0200. <3DAC7C39.A17C7C3C@hursley.ibm.com> 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: [Diffserv] APIs for diffserv From: itojun@iijlab.net Date: Wed, 16 Oct 2002 10:28:03 +0900 Message-Id: <20021016012803.96DC14B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 1) What work has been done with regards to specifying an API for >> setting the Traffic Class fields? Anything other than the IPv6 >> APIs? >There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001). >itojun may want to comment. the API for traffic class field is merged into 2292bis. see 2292bis for exact wording i've put in. basically ECN bits specified by user can be overridden by the kernel, if the kernel implements ECN mechanism (like for TCP). i stopped updating draft-itojun-ipv6-flowlabel-api-01.txt as there were a lot of discussions on flowlabel semantics, like draft-ietf-ipv6-flow-label-03.txt. my plan was to re-start on the API side once the flowlabel semantics discussion gets completed. btw, i don't think flowlabel relates to diffserv, am i right? 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 Tue Oct 15 19:59:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G2xl29026102; Tue, 15 Oct 2002 19:59:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G2xlqW026101; Tue, 15 Oct 2002 19:59:47 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G2xi29026094 for ; Tue, 15 Oct 2002 19:59:44 -0700 (PDT) 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 g9G2xnMq006366 for ; Tue, 15 Oct 2002 19:59:49 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06779 for ; Tue, 15 Oct 2002 20:59:44 -0600 (MDT) Message-ID: <004d01c274bf$e33cbfa0$226015ac@AlperVAIO> From: "Alper E. YEGIN" To: , "'Pekka Savola'" Cc: "'Nick 'Sharkey' Moore'" , References: <0c3b01c274a1$7eca2990$011aa8c0@eagleswings> Subject: Re: Optimistic DAD draft ... Date: Tue, 15 Oct 2002 19:57:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > > ... > > We cannot assume all MNs can "anticipate movement". Not all > > link-layers > > have this capability. > > A MN 'can anticipate movement' because that is what it does by > definition. What it may not be able to figure out is the candidate list > of where it may end up. What I really meant was this second one.. > The fact that some link layer implementations > have chosen not to expose knowledge of potential alternatives is > possibly due to a lack of requirements to do so. I know the 802.11 > implementation I am using is fully aware of the candidate set of layer 1 > associations, ..by listening to the baecons. But even that would require your wlan card to scan all the channels. They don't normally do that, until they really have to (i.e., current radio conditions are deteriorating), or your management application tells it to do so, because while scanning, it has to hold the data traffic. A card usually has only one transceiver. > though it doesn't attempt to bind the IP stack until I > select one. It would be easy for it to bind IP to all, but prioritize to > the selected one until it was out of range. If it did so, all possible > destinations could have run a full DAD in the background, well in > advance of the move. I don't think this is as easy as it sounds. Your MN has to: - collect a list of candidate access points (a costly scanning operation) - somehow map this information to associated prefix information, and an agent on the associated IP subnet (how?) - send a proxy-DAD request to that server (this protocol needs to be defined) ... and make sure this process concludes before your MN has to handover. > > Even if the MN implementation chose not to associate with all possible > layer 1 neighbors, the ones it does have an association with will also > be able to hear a partial list of the candidate set, and could provide > that to the MN if the implementation provided a path from the layer 1 > receiver to a control plane process. > > It is true that a standards effort can not assume that all > implementations will provide a full spectrum of capability, but it is > also true that it MUST NOT assume that ignoring a collision avoidance > system will not really do any harm. If people want to be mobile, but a Sure. Actually, my comment is not against what you are saying here. I guess an approach like a proxy-DAD can be a candidate solution to this problem. Another candidate is server-based DAD that I'm currently working on. It involves a server keeping track of currently used IP addresses on a subnet, and assisting mobiles that know how to consult this server. > specific link-layer doesn't provide the tools to make that work > correctly without problems, the link-layer will fade from the market > place. > > Tony alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 20:14:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G3Em29026194; Tue, 15 Oct 2002 20:14:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G3EmQW026193; Tue, 15 Oct 2002 20:14:48 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G3Ei29026186 for ; Tue, 15 Oct 2002 20:14:44 -0700 (PDT) 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 g9G3EoMq008432 for ; Tue, 15 Oct 2002 20:14:50 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05745 for ; Tue, 15 Oct 2002 21:14:44 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 100EB4B25; Wed, 16 Oct 2002 12:14:38 +0900 (JST) To: Arun Prasad Cc: ipng@sunroof.eng.sun.com In-reply-to: arun's message of Fri, 11 Oct 2002 16:15:29 +0100. <3DA6EB11.CA525C81@netlab.hcltech.com> 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: scope id querry From: itojun@iijlab.net Date: Wed, 16 Oct 2002 12:14:38 +0900 Message-Id: <20021016031438.100EB4B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi all, > Some doubts on the socket api for Ipv6. >* When a IPV6 packet is received throught the interface "recvmsg", how to get the > "zone_id" or "scope_id" for the received Ipv6 Addr. When the "recvmsg" > interface is called we get a structure in6_pktinfo, which has the ipv6 address and > "ipi6_ifindex".... Does this "ipi6_ifindex" serve as "zone_id". >Please clarify. sockaddr_in6 (which includes sin6_scope_id) will be available at the address specified by msg_name member in struct msghdr. 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 Tue Oct 15 21:26:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G4QB29026428; Tue, 15 Oct 2002 21:26:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G4QBUZ026427; Tue, 15 Oct 2002 21:26:11 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G4Q729026420 for ; Tue, 15 Oct 2002 21:26:07 -0700 (PDT) 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 g9G4QDMq018552 for ; Tue, 15 Oct 2002 21:26:13 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19781 for ; Tue, 15 Oct 2002 22:26:07 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KNQI32Y5XK9QWE1C@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 16 Oct 2002 14:25:34 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1DE4C20046; Wed, 16 Oct 2002 14:24:43 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 7A06D2005B; Wed, 16 Oct 2002 14:24:20 +1000 (EST) Date: Wed, 16 Oct 2002 14:24:20 +1000 From: Greg Daley Subject: Re: Optimistic DAD draft ... To: "Alper E. YEGIN" Cc: alh-ietf@tndh.net, "'Pekka Savola'" , "'Nick 'Sharkey' Moore'" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DACE9F4.40009@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <0c3b01c274a1$7eca2990$011aa8c0@eagleswings> <004d01c274bf$e33cbfa0$226015ac@AlperVAIO> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alper, > > Sure. Actually, my comment is not against what you are saying here. > I guess an approach like a proxy-DAD can be a candidate solution > to this problem. Another candidate is server-based DAD that I'm > currently working on. It involves a server keeping track of > currently used IP addresses on a subnet, and assisting mobiles > that know how to consult this server. Certainly Optimistic DAD is not particularly useful until you actually get to the link, but I think it provides a good fallback behaviour for mobile devices on networks which aren't willing to keep state. Stateful mechanisms are certainly more of a candidate for predictive and non-local address acquisition (may be matched with Predictive (Fast) Handovers, Hierarchical MIPv6). These are infrastructure based solutions though. MIPv6 principally operates on a low-infrastructure access network model. Optimistic DAD requires implementation only in the current node, and works with a predictable worst case performance on stock RFC 2461/2462 networks without additional support. I'm not sure which systems will gain a following, but I think that DAD's current 'timeout == success' philosophy will not stay around long. Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 15 22:21:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G5LH29026847; Tue, 15 Oct 2002 22:21:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G5LH8e026846; Tue, 15 Oct 2002 22:21:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G5LE29026839 for ; Tue, 15 Oct 2002 22:21:14 -0700 (PDT) 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 g9G5LJPG025151 for ; Tue, 15 Oct 2002 22:21:19 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11955 for ; Tue, 15 Oct 2002 23:21:13 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KNQK0VPQSQ9S3RMY@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 16 Oct 2002 15:21:02 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 509DF12C06C; Wed, 16 Oct 2002 15:21:01 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 0002912C03F; Wed, 16 Oct 2002 15:20:58 +1000 (EST) Date: Wed, 16 Oct 2002 15:20:58 +1000 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: James Kempf Cc: Brett Pentland , Thomas Narten , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DACF73A.40506@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <200210110110.g9B1AZ804398@cichlid.adsl.duke.edu> <03cd01c2749b$d8fb3590$146015ac@T23KEMPF> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, I guess you mean draft-mkhalil-ipv6-fastra-01.txt ? Greg Daley jak wrote: > So the deployment alternative with ND as defined in RFC 2461 and the base FMIPv6 > document if one wants faster 802.11 handovers is to set > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. Near term, > this is likely to be what people do. With this deployment, not only could the > above two problems with congestion occur, but the router is now subject to DoS > attacks. The advantage of the proposal in draft-khalil-ipng-fastra-00.txt is > that the authors believe it would reduce the potential for DoS attacks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 22:26:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G5QS29026904; Tue, 15 Oct 2002 22:26:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G5QSc5026903; Tue, 15 Oct 2002 22:26:28 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G5QO29026896 for ; Tue, 15 Oct 2002 22:26:24 -0700 (PDT) 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 g9G5QUMq028406 for ; Tue, 15 Oct 2002 22:26:30 -0700 (PDT) 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 WAA27132 for ; Tue, 15 Oct 2002 22:26:24 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9G5QIt65010; Wed, 16 Oct 2002 14:26:18 +0900 (JST) Date: Wed, 16 Oct 2002 14:27:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection 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: 72 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 11 Oct 2002 09:54:55 +0300 (EEST), >>>>> Pekka Savola said: > Perhaps we should have been more careful when discussing "how/when" to use > caching. > But well, 'htsearch' on RFC's for "cache" at http://rfc.eunet.fi (for > example) returns 520 RFC's. > I think there are examples of some caching specification, as well (e.g. > neighbor discovery, multicast, ...). The level of detail is of course > imporant. At least, very many specifications say, like "this and this > part is critical and should [or SHOULD] be cached". > One of my main worries was that it seemed that nobody even bothered to > mention that the steps could be complex and some caching mechanism > (possibly with some examples) should be implemented. IMO, it is not necessarily a problem that nobody bothered. I've not bothered (though I've made some comments on the draft) about the complexity because I didn't think it was a problem of the document based on my experiences on implementing and operating with the specification. In general, whether or not we need a cache depends on how severe the related performance issue is. And the performance in this case depends on several parameters such as the number of addresses and how many times each selection rule applies. Please let me explain my own environments. My laptop usually has quite a large number of addresses, and the property of the addresses varies much; it has 12 (unicast) addresses as of writing this, including the loopback, link-local, site-local, and global ones. It also has temporary addresses for privacy extension, and some of the temporary addresses are often deprecated due to the short lifetimes. (note: the number "12" will be much increased in a few days. I rebooted my laptop last night, so it has only one temporary address for each autoconfigured prefix. More and more new temporary addresses will come.) A few days ago, I checked statistics on the source address selection on the laptop. By then it had been running for 6.5 days. According to the statistics, about 76.8% of the pair-wise address comparisons had been broken by the rule 2 (Prefer appropriate scope) and the rule 3 (Avoid deprecated addresses). IMO, the rules 1-3 are quite simple and light, and do not affect the performance much. I don't have a quantitative result on the performance, but at least I've never felt untolerable performance degradation that can be considered due to the complexity of the source address selection. I can expect counterarguments against the analysis above; "it is just a single, personal, and limited environment." "perhaps your laptop has a fast CPU. Think about poor devices." "just because you don't feel degradation does not mean the performance issue is not a problem", etc... I understand all of them. But I'd say this comes from a *real* experiences on implementation and operation, not just from reading the specification. If you want to make the document include caching, please show us how the selection rules badly affect the performance and how the caching improves the performance degradation *with a working implementation*. (However, I must also say that it is not always the case that the requirement to implement caching comes from actual experiences with working implementations. So I may be a bit unfair here.) As a result, I don't think it is necessary to require (either SHOULD or MUST) caching in the address selection draft. I don't oppose to mentioning the fact that caching may improve the performance, though. 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 Oct 15 23:49:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G6ng29027153; Tue, 15 Oct 2002 23:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G6ng67027152; Tue, 15 Oct 2002 23:49:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G6nd29027145 for ; Tue, 15 Oct 2002 23:49:39 -0700 (PDT) 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 g9G6niPG009447 for ; Tue, 15 Oct 2002 23:49:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12410 for ; Wed, 16 Oct 2002 00:49:38 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9G6nUM10179; Wed, 16 Oct 2002 09:49:31 +0300 Date: Wed, 16 Oct 2002 09:49:30 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , Subject: Re: Implementation worries about default address selection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 16 Oct 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > IMO, it is not necessarily a problem that nobody bothered. I've not > bothered (though I've made some comments on the draft) about the > complexity because I didn't think it was a problem of the document > based on my experiences on implementing and operating with the > specification. It surely isn't a problem that John Doe Network User is likely to face, I agree -- the algorithm is not _that_ complex. > Please let me explain my own environments. My laptop usually has > quite a large number of addresses, and the property of the addresses > varies much; it has 12 (unicast) addresses as of writing this, > including the loopback, link-local, site-local, and global ones. It > also has temporary addresses for privacy extension, and some of the > temporary addresses are often deprecated due to the short lifetimes. > (note: the number "12" will be much increased in a few days. I > rebooted my laptop last night, so it has only one temporary address > for each autoconfigured prefix. More and more new temporary addresses > will come.) > > A few days ago, I checked statistics on the source address selection > on the laptop. By then it had been running for 6.5 days. According > to the statistics, about 76.8% of the pair-wise address comparisons > had been broken by the rule 2 (Prefer appropriate scope) and the rule > 3 (Avoid deprecated addresses). IMO, the rules 1-3 are quite simple > and light, and do not affect the performance much. The problems are likely to be seen with high use of UDP/ICMP, e.g. sending a Gigabit/FastEthernet full of UDP and checking how much that affects performance. > As a result, I don't think it is necessary to require (either SHOULD > or MUST) caching in the address selection draft. I don't oppose to > mentioning the fact that caching may improve the performance, though. I don't think we should require anything: if an implementation wants to do it the simple way, that's fine. But I believe there should be some more statements in the Implementation Considerations section, at least. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 00:26:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G7Qj29027368; Wed, 16 Oct 2002 00:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G7Qj43027367; Wed, 16 Oct 2002 00:26:45 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G7Qe29027360 for ; Wed, 16 Oct 2002 00:26:41 -0700 (PDT) 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 g9G7QkMq023690 for ; Wed, 16 Oct 2002 00:26:46 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00840; Wed, 16 Oct 2002 01:26:40 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9G7QZt65950; Wed, 16 Oct 2002 16:26:35 +0900 (JST) Date: Wed, 16 Oct 2002 16:27:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Erik Nordmark , Subject: Re: Implementation worries about default address selection 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: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 16 Oct 2002 09:49:30 +0300 (EEST), >>>>> Pekka Savola said: > The problems are likely to be seen with high use of UDP/ICMP, e.g. > sending a Gigabit/FastEthernet full of UDP and checking how much that > affects performance. (if you're not requiring to add caching as MUST or SHOULD, I don't care, but) such an environment will cause other performance issues as well. I guess you cannot convince others to make an additional requirement just by warring about a special case. BTW (this is almost an off-topic though): one of practical examples of this is a heavily busy DNS server. However, the source address selection does not matter at least for a widely used implementation, BIND. It explicitly specifies the source address to make it sure that the query's destination address equals to the reply's source address. >> As a result, I don't think it is necessary to require (either SHOULD >> or MUST) caching in the address selection draft. I don't oppose to >> mentioning the fact that caching may improve the performance, though. > I don't think we should require anything: if an implementation wants to do > it the simple way, that's fine. But I believe there should be some more > statements in the Implementation Considerations section, at least. If you're not requiring anything, I'm just fine. I made comments here because you actually seemed to require caching in the address selection draft. And, it seems to me that's why others objected to your messages (at least to some extent) in this list. I don't see the need for the additional consideration in the Implementation Considerations section either, but I don't oppose to mentioning this there. Considering implication much is in general a good thing. Perhaps this is up to the author (who have not appeared in this thread...). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 01:06:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G86t29027478; Wed, 16 Oct 2002 01:06:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9G86tkd027477; Wed, 16 Oct 2002 01:06:55 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9G86p29027470 for ; Wed, 16 Oct 2002 01:06:51 -0700 (PDT) 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 g9G86uMq000316 for ; Wed, 16 Oct 2002 01:06:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01428 for ; Wed, 16 Oct 2002 02:06:51 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9G85Qt66226; Wed, 16 Oct 2002 17:05:26 +0900 (JST) Date: Wed, 16 Oct 2002 17:06:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Arun Prasad Cc: ipng@sunroof.eng.sun.com Subject: Re: scope id querry In-Reply-To: <3DA6EB11.CA525C81@netlab.hcltech.com> References: <3DA6EB11.CA525C81@netlab.hcltech.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: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 11 Oct 2002 16:15:29 +0100, >>>>> Arun Prasad said: > Some doubts on the socket api for Ipv6. > * When a IPV6 packet is received throught the interface "recvmsg", how to get the > "zone_id" or "scope_id" for the received Ipv6 Addr. When the "recvmsg" > interface is called we get a structure in6_pktinfo, which has the ipv6 address and > "ipi6_ifindex".... Does this "ipi6_ifindex" serve as "zone_id". Not really (at least technically). ipi6_ifindex specifies the "interface ID" of the receiving interface. The "zone ID" depends on the address type (i.e. link-local, site-local, global, etc), and, in general, interface IDs are different from zone IDs for wider scope types. However, interface scope is the narrowest one, so you can get the zone ID for any type of scope from the interface ID. For further information, see draft-ietf-ipngwg-scoping-arch-04.txt. Section 1.3 of the KAME IMPLEMENTATION notes may also give you hints. The latest one is available at: http://orange.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION?rev=1.315 JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 03:31:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GAVK29028023; Wed, 16 Oct 2002 03:31:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GAVKni028022; Wed, 16 Oct 2002 03:31:20 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GAVH29028015 for ; Wed, 16 Oct 2002 03:31:17 -0700 (PDT) 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 g9GAVNMq017428 for ; Wed, 16 Oct 2002 03:31:23 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07772 for ; Wed, 16 Oct 2002 04:31:15 -0600 (MDT) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP908T52; Wed, 16 Oct 2002 16:01:35 +0530 Received: from netlab.hcltech.com ([192.168.19.129]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id QAA17804 for ; Wed, 16 Oct 2002 16:30:38 +0530 Message-ID: <3DAD7F66.DEBCF919@netlab.hcltech.com> Date: Wed, 16 Oct 2002 16:01:58 +0100 From: Arun Prasad X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: scope id querry References: <3DA6EB11.CA525C81@netlab.hcltech.com> Content-Type: multipart/alternative; boundary="------------2B63DF94FC39C014E6C9EFD0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------2B63DF94FC39C014E6C9EFD0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Fri, 11 Oct 2002 16:15:29 +0100, > >>>>> Arun Prasad said: > > > Some doubts on the socket api for Ipv6. > > * When a IPV6 packet is received throught the interface "recvmsg", how to get the > > "zone_id" or "scope_id" for the received Ipv6 Addr. When the "recvmsg" > > interface is called we get a structure in6_pktinfo, which has the ipv6 address and > > "ipi6_ifindex".... Does this "ipi6_ifindex" serve as "zone_id". > > Not really (at least technically). ipi6_ifindex specifies the > "interface ID" of the receiving interface. The "zone ID" depends on > the address type (i.e. link-local, site-local, global, etc), and, in > general, interface IDs are different from zone IDs for wider scope > types. However, interface scope is the narrowest one, so you can get > the zone ID for any type of scope from the interface ID. > > For further information, see draft-ietf-ipngwg-scoping-arch-04.txt. > > Section 1.3 of the KAME IMPLEMENTATION notes may also give you hints. > The latest one is available at: > http://orange.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION?rev=1.315 > sockaddr_in6 (which includes sin6_scope_id) will be available at the address specified by msg_name member in struct msghdr. itojun Above is one of the replies I received..... Taking both ur reply and itojun's reply can I take that "sin6_scope_id" present in the fromAddr returned ( from recvfrom call) as the zone identifier ( and getting the zone from the scope type of the fromAddr) ?? Thanks -arun > > 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 > -------------------------------------------------------------------- -- **************************************************************** V.ARUN PRASAD HCL Technologies Ltd., Networking Technologies Lab, Ground Floor, Block - 1, Chandamama Building, 184 to 188,190,192 & 196, NSK Road, Vadapalani, Chennai - 600 026 Phone: Off: +91-44-3728366/67/69, +91-44-3728156/57 Extn. 1133 Fax: +91-44-4806640 **************************************************************** --------------2B63DF94FC39C014E6C9EFD0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hello,

JINMEI Tatuya / $B?@L@C#:H(B wrote:

>>>>> On Fri, 11 Oct 2002 16:15:29 +0100,
>>>>> Arun Prasad <arun@netlab.hcltech.com> said:

>     Some doubts on the socket api for Ipv6.
> * When a IPV6 packet is received throught the interface "recvmsg", how to get  the
>     "zone_id" or "scope_id"  for the received Ipv6 Addr. When the "recvmsg"
>     interface is called we get a structure in6_pktinfo, which has the ipv6 address and
>     "ipi6_ifindex".... Does this "ipi6_ifindex" serve as "zone_id".

Not really (at least technically).  ipi6_ifindex specifies the
"interface ID" of the receiving interface.  The "zone ID" depends on
the address type (i.e. link-local, site-local, global, etc), and, in
general, interface IDs are different from zone IDs for wider scope
types.  However, interface scope is the narrowest one, so you can get
the zone ID for any type of scope from the interface ID.

For further information, see draft-ietf-ipngwg-scoping-arch-04.txt.

Section 1.3 of the KAME IMPLEMENTATION notes may also give you hints.
The latest one is available at:
http://orange.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION?rev=1.315
 

sockaddr_in6 (which includes sin6_scope_id) will be available
        at the address specified by msg_name member in struct msghdr.

itojun

Above is one of the replies I received..... Taking both ur reply and itojun's reply
can I take that "sin6_scope_id" present in the fromAddr returned ( from recvfrom
call) as the zone identifier ( and getting the zone from the scope type of the
fromAddr) ??

Thanks
-arun

 
                                        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
--------------------------------------------------------------------
--
****************************************************************
V.ARUN PRASAD
HCL Technologies Ltd.,
Networking Technologies Lab,
Ground Floor, Block - 1, Chandamama Building,
184 to 188,190,192 & 196, NSK Road,
Vadapalani,
Chennai - 600 026

Phone: Off: +91-44-3728366/67/69, +91-44-3728156/57 Extn. 1133
Fax: +91-44-4806640
****************************************************************
  --------------2B63DF94FC39C014E6C9EFD0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 07:24:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GEOY29028590; Wed, 16 Oct 2002 07:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GEOXwP028589; Wed, 16 Oct 2002 07:24:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GEOS29028582 for ; Wed, 16 Oct 2002 07:24:28 -0700 (PDT) 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 g9GEOXPG009853 for ; Wed, 16 Oct 2002 07:24:33 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29210 for ; Wed, 16 Oct 2002 07:24:27 -0700 (PDT) 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 g9GEOHSZ043796; Wed, 16 Oct 2002 16:24:18 +0200 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 g9GEOEmd032450; Wed, 16 Oct 2002 16:24:15 +0200 Received: from gsine01.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57944 from ; Wed, 16 Oct 2002 16:24:09 +0200 Message-Id: <3DAD7682.E201EE57@hursley.ibm.com> Date: Wed, 16 Oct 2002 16:24:02 +0200 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: itojun@iijlab.net Cc: Thomas Narten , diffserv@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [Diffserv] APIs for diffserv References: <20021016012803.96DC14B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> 1) What work has been done with regards to specifying an API for > >> setting the Traffic Class fields? Anything other than the IPv6 > >> APIs? > >There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001). > >itojun may want to comment. > > the API for traffic class field is merged into 2292bis. see 2292bis > for exact wording i've put in. basically ECN bits specified by user > can be overridden by the kernel, if the kernel implements ECN > mechanism (like for TCP). > > i stopped updating draft-itojun-ipv6-flowlabel-api-01.txt as there were > a lot of discussions on flowlabel semantics, like > draft-ietf-ipv6-flow-label-03.txt. > my plan was to re-start on the API side once the flowlabel semantics > discussion gets completed. btw, i don't think flowlabel relates to > diffserv, am i right? That is slightly contentious. The flow-label draft does not define use cases, but if that draft is approved in its present form I know how to define a diffserv use case for the flow label (and there are several other use cases). However, it shouldn't affect the socket API discussion. 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 Oct 16 07:52:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GEq629028731; Wed, 16 Oct 2002 07:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GEq64Q028730; Wed, 16 Oct 2002 07:52:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GEq329028723 for ; Wed, 16 Oct 2002 07:52:03 -0700 (PDT) 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 g9GEq9PG014307 for ; Wed, 16 Oct 2002 07:52:09 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02937 for ; Wed, 16 Oct 2002 08:52:02 -0600 (MDT) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9GEpjiZ010862; Wed, 16 Oct 2002 10:51:45 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 16 Oct 2002 10:51:50 -0400 Message-ID: <3DAD7C75.3030603@nc.rr.com> Date: Wed, 16 Oct 2002 10:49:25 -0400 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: Keith Moore CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt References: <200210112306.g9BN6V004831@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, Keith Moore wrote: >> My point is that I believe that a clean separation should be made >>between global addresses and scoped addresses. We fully understand >>how globals and link-locals work. All the others are still being >>hashed out. If we make this break, the address architecture can >>move along the standards track. The (great amount of) additional >>work that needs to be done on scoped addresses can be carried out >>under the scoped address architecture. > > > actually I'd claim that we don't really understand how link-locals > work, at least not from the applications viewpoint. but I enthusiastically > support the idea of separating the work on globals from the work > on scoped addresses. I believe we do have a good understanding on how link-locals work with utility protocols (ICMP, ND, MLD, routing protocols). That is why the LL are needed in the base addressing architecture. As for LL and user apps, I can't speak authoratively on the subject. 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 Oct 16 08:15:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFFQ29028855; Wed, 16 Oct 2002 08:15:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFFH3b028854; Wed, 16 Oct 2002 08:15:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFFC29028843 for ; Wed, 16 Oct 2002 08:15:12 -0700 (PDT) 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 g9GFFIPG018600 for ; Wed, 16 Oct 2002 08:15:18 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00927 for ; Wed, 16 Oct 2002 09:15:12 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id DB616A77; Wed, 16 Oct 2002 11:15:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:15:11 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:15:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ0mizVAco54366QaipEGAcGDKyTgAjDx3g From: "Bound, Jim" To: "Alper E. YEGIN" , , "Pekka Savola" Cc: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 16 Oct 2002 15:15:11.0646 (UTC) FILETIME=[D240BBE0:01C27526] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFFD29028844 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper, Simply because of address spoof DOS we must at least permit DAD. The cost is only at node-on. Now the timers and lifetimes administration for a mobile network could be a problem but that is tunable. I believe we are talking miliseconds. What we need are some tests. I will ask our folks to test our handhelds for DAD timings. But any implementation can turn anything it wants off for v6. We can say MUST or SHOULD but users may or may not use it. I am not comfortable changing DAD for anything here quite yet based on the arguments on the "for" side at all. /jim -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, October 15, 2002 5:12 PM To: alh-ietf@tndh.net; 'Pekka Savola' Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Hi Tony, > True, but the term 'hand-off' implies a make-before-break process, > else the MN is just establishing itself on a new link. Given it has > the opportunity to be aware of multiple links, it can decide when to > switch. I am arguing that it complete DAD 'before' it makes that > decision, not after. I don't think we can consider all "handoffs" as 'make-before-break'. There exists some link-layer technologies that allow this, but not all have such capability. Completing DAD before handover requires either movement anticipation or make-before-break, both of which are not widely applicable. Therefore solving DAD latency for general case is a valid approach, imo. alper > > Tony > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Tuesday, October 15, 2002 1:32 PM > > To: Tony Hain > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > Subject: RE: Optimistic DAD draft ... > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > [...] it would seem the prudent thing for a MN to do is > > establish DAD > > > for all candidate prefixes well before it is ready to start using > > > them. [...] > > > > Isn't there a problem with how this could be done, as > > currently specified? > > > > One can't perform DAD before being on the link. > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > 'Sharkey' Moore > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > To: ipng@sunroof.eng.sun.com > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > One of the big issues in getting low-latency > > > > handovers working for IPv6 mobility is the long delay involved > > > > in > > > > completing DAD. > > > > > > > > One option is to allow the Mobile Node to communicate while the > > > > address is still Tentative (optimistically assuming that DAD > > > > will succeed), but to adjust its ND / SAA behaviour in order to > > > > minimize disruption in case of an address conflict (and maintain > > > > correct interoperation with > > unmodified nodes). > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > and I've formalized my thoughts into an internet draft, > > which should > > > > get published soon. In the meantime, you can find it at > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > I'd be interested in your opinions on the draft, and its > > > > potential suitability for standards track. > > > > > > > > > > > > cheers, > > > > Nick > > > > -- > > > > Nick 'Sharkey' Moore > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 > > > -------------------------------------------------------------------- > > > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:15:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFFt29028865; Wed, 16 Oct 2002 08:15:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFFtPb028864; Wed, 16 Oct 2002 08:15:55 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFFo29028857 for ; Wed, 16 Oct 2002 08:15:50 -0700 (PDT) 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 g9GFFuMq000619 for ; Wed, 16 Oct 2002 08:15:56 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01372 for ; Wed, 16 Oct 2002 09:15:51 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AA70FA54C; Wed, 16 Oct 2002 11:15:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:15:50 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:15:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ0mlHOLiWyKjkeSC23EJTjw0kj4QAjIgWg From: "Bound, Jim" To: "Nick 'Sharkey' Moore" , "Tony Hain" Cc: "Charles E. Perkins" , "Pekka Savola" , X-OriginalArrivalTime: 16 Oct 2002 15:15:50.0490 (UTC) FILETIME=[E967DBA0:01C27526] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFFp29028858 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I simply cannot believe it is 1000 ms. Like I said lets get some empircal data. /jim -----Original Message----- From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] Sent: Tuesday, October 15, 2002 5:24 PM To: Tony Hain Cc: 'Charles E. Perkins'; 'Pekka Savola'; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... On Tue, Oct 15, 2002 at 03:18:34PM -0700, Tony Hain wrote: > > It seems like this would be a bigger latency concern than DAD. 1000ms is a long time by anyone's standards! > Maybe I just don't understand the technology well enough, but I from > my limited perspective it would seem that the current GGSN would know > which radio system the MN was attached to, and therefore could figure > out the candidate set of destinations for a hand-off. If only the networks we are experimenting with were so civilized! There's a lot of interest in getting MIPv6 working on 802.11 networks though ... -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 08:17:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFH029028893; Wed, 16 Oct 2002 08:17:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFH0pY028892; Wed, 16 Oct 2002 08:17:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFGu29028885 for ; Wed, 16 Oct 2002 08:16:56 -0700 (PDT) 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 g9GFH2PG018921 for ; Wed, 16 Oct 2002 08:17:02 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19809 for ; Wed, 16 Oct 2002 09:16:56 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1D7822CFA; Wed, 16 Oct 2002 11:16:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:16:54 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:16:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ0moC+3BYNrzFnTzakB0CVAq4hcQAjIEzg From: "Bound, Jim" To: , "Charles E. Perkins" Cc: "Pekka Savola" , "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 16 Oct 2002 15:16:54.0896 (UTC) FILETIME=[0FCB6F00:01C27527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFGv29028886 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I do understand it exactly and you are 100% correct. Lets do some testing. /jim -----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net] Sent: Tuesday, October 15, 2002 5:19 PM To: 'Charles E. Perkins' Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com Subject: RE: Optimistic DAD draft ... inline > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Charles > E. Perkins > Sent: Tuesday, October 15, 2002 2:47 PM > To: alh-ietf@tndh.net > Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > Hello Tony, > > It is possible to have nice handoffs even with > break-before-make, as long as "break" is not > too lengthy. It seems like this would be a bigger latency concern than DAD. > If the determination about the > destination network is available in time, completing > DAD before switching is a good idea -- whether or > not the handoff is "break-before-make". Maybe I just don't understand the technology well enough, but I from my limited perspective it would seem that the current GGSN would know which radio system the MN was attached to, and therefore could figure out the candidate set of destinations for a hand-off. That list could be forwarded to the MN, so personal policy and signal strength could be applied to sort the list to come up with the best candidates. With that an out of band predictive DAD could be done. This would make much more sense than moving, stepping on an existing node, then backing off. It seems that a little bit of overhead traffic is better than dropping 2 connections. > > This is under discussion within the seamoby working > group. We have a draft about it, and an optimistic > DAD scheme. When my head rises more than an millimeter > above water, I'll read the draft in the Subject: line > (glub, glub). > > Regards, > Charlie P. > > > Tony Hain wrote: > > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can > decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to > start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as currently > > > specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: ipng@sunroof.eng.sun.com > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > handovers working > > > > > for IPv6 mobility is the long delay involved in > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate > while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour > in order to > > > > > minimize disruption in case of an address conflict > (and maintain > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > and I've > > > > > formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the > draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home 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 > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 08:18:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFIv29028928; Wed, 16 Oct 2002 08:18:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFIvor028927; Wed, 16 Oct 2002 08:18:57 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFIr29028918 for ; Wed, 16 Oct 2002 08:18:53 -0700 (PDT) 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 g9GFIxMq001442 for ; Wed, 16 Oct 2002 08:18:59 -0700 (PDT) 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 JAA21101 for ; Wed, 16 Oct 2002 09:18:54 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8E5D4900; Wed, 16 Oct 2002 11:18:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:18:53 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:18:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ0oDQpTR98JsevSyOQ5+2cHdEKLQAhwqlw From: "Bound, Jim" To: "Alper E. YEGIN" , , "Pekka Savola" Cc: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 16 Oct 2002 15:18:53.0332 (UTC) FILETIME=[56635540:01C27527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFIs29028920 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper, None of us working on this are even clear layer 3 handover will ever work? Not sure if that matters does it? Are we talking about the future? Thanks /jim -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, October 15, 2002 5:43 PM To: alh-ietf@tndh.net; 'Pekka Savola' Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... > > > True, but the term 'hand-off' implies a make-before-break process, > > > else the MN is just establishing itself on a new link. Given it has > > > the opportunity to be aware of multiple links, it can > > decide when to > > > switch. I am arguing that it complete DAD 'before' it makes that > > > decision, not after. > > > > I don't think we can consider all "handoffs" as > > 'make-before-break'. There exists some link-layer > > technologies that allow this, but not all have such capability. > > Then DAD latency should be the least of the concerns. Not really. For example 802.11b (link-layer) handover can take something like 200ms, and DAD would take 1sec on that link. People are already working on shrinking link-layer handover latency, and some should do the same for DAD as well. > > > > > Completing DAD before handover requires either movement > > anticipation or make-before-break, both of which are not > > widely applicable. Therefore solving DAD latency for general > > case is a valid approach, imo. > > My argument is that all MNs anticipate movement, and establish DAD > before they really make the move. Yes this will generate some overhead > if the node doesn't move, but that is a minor cost in the grand scheme > of things. We cannot assume all MNs can "anticipate movement". Not all link-layers have this capability. alper > > Tony > > > > > alper > > > > > > > > > > > > > > Tony > > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > > To: Tony Hain > > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > > [...] it would seem the prudent thing for a MN to do is > > > > establish DAD > > > > > for all candidate prefixes well before it is ready to > > start using > > > > > them. [...] > > > > > > > > Isn't there a problem with how this could be done, as currently > > > > specified? > > > > > > > > One can't perform DAD before being on the link. > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > > 'Sharkey' Moore > > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > > To: ipng@sunroof.eng.sun.com > > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > > > One of the big issues in getting low-latency handovers > > > > > > working for IPv6 mobility is the long delay > > involved > > > > > > in > > > > > > completing DAD. > > > > > > > > > > > > One option is to allow the Mobile Node to communicate > > while the > > > > > > address is still Tentative (optimistically assuming that DAD > > > > > > will succeed), but to adjust its ND / SAA behaviour > > in order to > > > > > > minimize disruption in case of an address conflict > > (and maintain > > > > > > correct interoperation with > > > > unmodified nodes). > > > > > > > > > > > > We've kicked the idea around a little on mobile-ip, and I've > > > > > > formalized my thoughts into an internet draft, > > > > which should > > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > > > I'd be interested in your opinions on the > > draft, and its > > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > > > > cheers, > > > > > > Nick > > > > > > -- > > > > > > Nick 'Sharkey' Moore > > > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > IETF IPng Working Group Mailing List > > > > > > IPng Home 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 > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > -- > > > > Pekka Savola "Tell me of difficulties surmounted, > > > > Netcore Oy not those you stumble over and fall" > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of > > > > Swords > > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:20:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFK329028977; Wed, 16 Oct 2002 08:20:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFK3hc028976; Wed, 16 Oct 2002 08:20:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFJx29028966 for ; Wed, 16 Oct 2002 08:19:59 -0700 (PDT) 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 g9GFK4PG019653 for ; Wed, 16 Oct 2002 08:20:05 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21374 for ; Wed, 16 Oct 2002 09:19:58 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 358E32D11; Wed, 16 Oct 2002 11:19:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:19:56 -0400 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: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 16 Oct 2002 11:19:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing RS Reply Timing for Mobile IPv6 Thread-Index: AcJ0oNFfG9K9GbwFTrO1OikA+1FlZwAhprwA From: "Bound, Jim" To: "James Kempf" , "Brett Pentland" , "Thomas Narten" Cc: X-OriginalArrivalTime: 16 Oct 2002 15:19:56.0988 (UTC) FILETIME=[7C5477C0:01C27527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFK029028967 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, Have you actually tested this with implementation? Or is this theoretical debate? Thanks /jim -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, October 15, 2002 5:40 PM To: Brett Pentland; Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 Thomas, > Seems to me then that this document is a bit narrowly scoped and may > even miss the point. Don't we need to look at the overall problem and > then see what can be done to address the overall problem adequately? > In general, I don't know that its all that useful to focus on a narrow > part of a bigger problem unless the bigger problem is sufficiently > understood that the point solution is understood to be an important > and useful component of it. How do we know that this change will make > any significant difference in practice given the general problem? > You are right that this document is fairly narrowly scoped. To solve the full problem, it requires other parts of the ND process, specifically DAD, to be accelerated as well. Additionally, as was brought up on the list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As was also brought up on the list, this can lead to congestion when mobile nodes move in concert, or when an access point crashes. The FMIPv6 work is certainly a more comprehensive solution, however, the currently understanding of how FMIPv6 would work together with 802.11 is not encouraging. There is, of course, an argument about how much the IETF should modify its specifications to be implementable on a specific link layer. However, for 802.11 to work well with FMIP, there would either need to be a major change in the current firmware implementations for anticipated handover, or an additional protocol would be needed between the AP and the AR for conveying the reassociation link up trigger to the AR, or some special kind of security association would be required between the old AR and the MN in order to do unsolicited FBU signaling from the AR to the MN. The IETF can do some work on the last two of these but the first one is entirely controlled by the IEEE and, worse, by card manufacturers who may or may not implement given that IEEE has no standard. So the deployment alternative with ND as defined in RFC 2461 and the base FMIPv6 document if one wants faster 802.11 handovers is to set MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. Near term, this is likely to be what people do. With this deployment, not only could the above two problems with congestion occur, but the router is now subject to DoS attacks. The advantage of the proposal in draft-khalil-ipng-fastra-00.txt is that the authors believe it would reduce the potential for DoS attacks. Whether or not this is enough of an improvement over the RS reply algorithm as defined by RFC 2461 to standardize, is something for WG and the IESG to decide. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:20:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFKl29029018; Wed, 16 Oct 2002 08:20:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFKlSQ029017; Wed, 16 Oct 2002 08:20:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFKh29029010 for ; Wed, 16 Oct 2002 08:20:43 -0700 (PDT) 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 g9GFKnPG019806 for ; Wed, 16 Oct 2002 08:20:49 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04618 for ; Wed, 16 Oct 2002 08:20:43 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GFKTm14181; Wed, 16 Oct 2002 18:20:29 +0300 Date: Wed, 16 Oct 2002 18:20:29 +0300 (EEST) From: Pekka Savola To: Keith Moore cc: Brian Haberman , Bob Hinden , Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200210112306.g9BN6V004831@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Oct 2002, Keith Moore wrote: > > My point is that I believe that a clean separation should be made > > between global addresses and scoped addresses. We fully understand > > how globals and link-locals work. All the others are still being > > hashed out. If we make this break, the address architecture can > > move along the standards track. The (great amount of) additional > > work that needs to be done on scoped addresses can be carried out > > under the scoped address architecture. > > actually I'd claim that we don't really understand how link-locals > work, at least not from the applications viewpoint. but I enthusiastically > support the idea of separating the work on globals from the work > on scoped addresses. Agree. Consider a TCP session to a node which has fe80::1 assigned on two of its interfaces, at least sounds potentially problematic. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:28:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFSv29029325; Wed, 16 Oct 2002 08:28:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFSvF5029324; Wed, 16 Oct 2002 08:28:57 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFSq29029308 for ; Wed, 16 Oct 2002 08:28:53 -0700 (PDT) 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 g9GFSwMq003488 for ; Wed, 16 Oct 2002 08:28:58 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10855 for ; Wed, 16 Oct 2002 09:28:53 -0600 (MDT) Message-ID: <003301c27528$7fa3ad50$146015ac@T23KEMPF> From: "James Kempf" To: Cc: "Brett Pentland" , "Thomas Narten" , References: <200210110110.g9B1AZ804398@cichlid.adsl.duke.edu> <03cd01c2749b$d8fb3590$146015ac@T23KEMPF> <3DACF73A.40506@eng.monash.edu.au> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 16 Oct 2002 08:27:09 -0700 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 Yes, sorry. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Brett Pentland" ; "Thomas Narten" ; Sent: Tuesday, October 15, 2002 10:20 PM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > Hi James, > > I guess you mean draft-mkhalil-ipv6-fastra-01.txt ? > > Greg Daley > > jak wrote: > > So the deployment alternative with ND as defined in RFC 2461 and the base FMIPv6 > > document if one wants faster 802.11 handovers is to set > > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. Near term, > > this is likely to be what people do. With this deployment, not only could the > > above two problems with congestion occur, but the router is now subject to DoS > > attacks. The advantage of the proposal in draft-khalil-ipng-fastra-00.txt is > > that the authors believe it would reduce the potential for DoS attacks. > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:42:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFge29029564; Wed, 16 Oct 2002 08:42:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFgdu4029563; Wed, 16 Oct 2002 08:42:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFga29029556 for ; Wed, 16 Oct 2002 08:42:36 -0700 (PDT) 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 g9GFggPG024370 for ; Wed, 16 Oct 2002 08:42:42 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21125 for ; Wed, 16 Oct 2002 09:42:36 -0600 (MDT) Message-ID: <008a01c2752a$68255af0$146015ac@T23KEMPF> From: "James Kempf" To: "Bound, Jim" , "Brett Pentland" , "Thomas Narten" Cc: References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953F@tayexc13.americas.cpqcorp.net> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 16 Oct 2002 08:40:50 -0700 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 Jim, We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses the 802.11 reassociate for a link up trigger to cause the RS. There is a substantial decrease in packet loss, on the order of the router beacon. This requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We have not implemented the optimization described in the draft yet. jak ----- Original Message ----- From: "Bound, Jim" To: "James Kempf" ; "Brett Pentland" ; "Thomas Narten" Cc: Sent: Wednesday, October 16, 2002 8:19 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > James, > > Have you actually tested this with implementation? Or is this > theoretical debate? > > Thanks > /jim > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 5:40 PM > To: Brett Pentland; Thomas Narten > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > Thomas, > > > Seems to me then that this document is a bit narrowly scoped and may > > even miss the point. Don't we need to look at the overall problem and > > then see what can be done to address the overall problem adequately? > > In general, I don't know that its all that useful to focus on a narrow > > > part of a bigger problem unless the bigger problem is sufficiently > > understood that the point solution is understood to be an important > > and useful component of it. How do we know that this change will make > > > any significant difference in practice given the general problem? > > > > You are right that this document is fairly narrowly scoped. To solve the > full problem, it requires other parts of the ND process, specifically > DAD, to be accelerated as well. Additionally, as was brought up on the > list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As > was also brought up on the list, this can lead to congestion when mobile > nodes move in concert, or when an access point crashes. > > The FMIPv6 work is certainly a more comprehensive solution, however, the > currently understanding of how FMIPv6 would work together with 802.11 is > not encouraging. There is, of course, an argument about how much the > IETF should modify its specifications to be implementable on a specific > link layer. However, for 802.11 to work well with FMIP, there would > either need to be a major change in the current firmware implementations > for anticipated handover, or an additional protocol would be needed > between the AP and the AR for conveying the reassociation link up > trigger to the AR, or some special kind of security association would be > required between the old AR and the MN in order to do unsolicited FBU > signaling from the AR to the MN. The IETF can do some work on the last > two of these but the first one is entirely controlled by the IEEE and, > worse, by card manufacturers who may or may not implement given that > IEEE has no standard. > > So the deployment alternative with ND as defined in RFC 2461 and the > base FMIPv6 document if one wants faster 802.11 handovers is to set > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. > Near term, this is likely to be what people do. With this deployment, > not only could the above two problems with congestion occur, but the > router is now subject to DoS attacks. The advantage of the proposal in > draft-khalil-ipng-fastra-00.txt is that the authors believe it would > reduce the potential for DoS attacks. > > Whether or not this is enough of an improvement over the RS reply > algorithm as defined by RFC 2461 to standardize, is something for WG and > the IESG to decide. > > jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 08:50:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFoZ29029642; Wed, 16 Oct 2002 08:50:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GFoYSu029641; Wed, 16 Oct 2002 08:50:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GFoV29029634 for ; Wed, 16 Oct 2002 08:50:31 -0700 (PDT) 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 g9GFobMq008540 for ; Wed, 16 Oct 2002 08:50:37 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAB27802 for ; Wed, 16 Oct 2002 09:50:31 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 637AD2FCF; Wed, 16 Oct 2002 11:50:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 11:50:31 -0400 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: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 16 Oct 2002 11:50:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9549@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing RS Reply Timing for Mobile IPv6 Thread-Index: AcJ1KqF69ur7U4RLR+i3VkNjnkr7oQAAQ+pw From: "Bound, Jim" To: "James Kempf" , "Brett Pentland" , "Thomas Narten" Cc: X-OriginalArrivalTime: 16 Oct 2002 15:50:31.0242 (UTC) FILETIME=[C1A16AA0:01C2752B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GFoV29029635 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, Thanks. I will ask our folks to do the same and see if we see the same. Will take me some time. /jim -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, October 16, 2002 10:41 AM To: Bound, Jim; Brett Pentland; Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 Jim, We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses the 802.11 reassociate for a link up trigger to cause the RS. There is a substantial decrease in packet loss, on the order of the router beacon. This requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We have not implemented the optimization described in the draft yet. jak ----- Original Message ----- From: "Bound, Jim" To: "James Kempf" ; "Brett Pentland" ; "Thomas Narten" Cc: Sent: Wednesday, October 16, 2002 8:19 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > James, > > Have you actually tested this with implementation? Or is this > theoretical debate? > > Thanks > /jim > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 5:40 PM > To: Brett Pentland; Thomas Narten > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > Thomas, > > > Seems to me then that this document is a bit narrowly scoped and may > > even miss the point. Don't we need to look at the overall problem > > and then see what can be done to address the overall problem > > adequately? In general, I don't know that its all that useful to > > focus on a narrow > > > part of a bigger problem unless the bigger problem is sufficiently > > understood that the point solution is understood to be an important > > and useful component of it. How do we know that this change will > > make > > > any significant difference in practice given the general problem? > > > > You are right that this document is fairly narrowly scoped. To solve > the full problem, it requires other parts of the ND process, > specifically DAD, to be accelerated as well. Additionally, as was > brought up on the list, the MN must also decrease > MAX_RTR_SOLICITATION_DELAY to zero. As was also brought up on the > list, this can lead to congestion when mobile nodes move in concert, > or when an access point crashes. > > The FMIPv6 work is certainly a more comprehensive solution, however, > the currently understanding of how FMIPv6 would work together with > 802.11 is not encouraging. There is, of course, an argument about how > much the IETF should modify its specifications to be implementable on > a specific link layer. However, for 802.11 to work well with FMIP, > there would either need to be a major change in the current firmware > implementations for anticipated handover, or an additional protocol > would be needed between the AP and the AR for conveying the > reassociation link up trigger to the AR, or some special kind of > security association would be required between the old AR and the MN > in order to do unsolicited FBU signaling from the AR to the MN. The > IETF can do some work on the last two of these but the first one is > entirely controlled by the IEEE and, worse, by card manufacturers who > may or may not implement given that IEEE has no standard. > > So the deployment alternative with ND as defined in RFC 2461 and the > base FMIPv6 document if one wants faster 802.11 handovers is to set > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. > Near term, this is likely to be what people do. With this deployment, > not only could the above two problems with congestion occur, but the > router is now subject to DoS attacks. The advantage of the proposal in > draft-khalil-ipng-fastra-00.txt is that the authors believe it would > reduce the potential for DoS attacks. > > Whether or not this is enough of an improvement over the RS reply > algorithm as defined by RFC 2461 to standardize, is something for WG > and the IESG to decide. > > jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 09:03:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GG3f29029752; Wed, 16 Oct 2002 09:03:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GG3frO029751; Wed, 16 Oct 2002 09:03:41 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GG3b29029744 for ; Wed, 16 Oct 2002 09:03:37 -0700 (PDT) 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 g9GG3gMq011681 for ; Wed, 16 Oct 2002 09:03:43 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25052 for ; Wed, 16 Oct 2002 10:03:32 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BAA744B25; Thu, 17 Oct 2002 01:03:30 +0900 (JST) To: Brian Haberman Cc: Keith Moore , ipng@sunroof.eng.sun.com In-reply-to: bkhabs's message of Wed, 16 Oct 2002 10:49:25 -0400. <3DAD7C75.3030603@nc.rr.com> 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: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt From: itojun@iijlab.net Date: Thu, 17 Oct 2002 01:03:30 +0900 Message-Id: <20021016160330.BAA744B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Keith Moore wrote: >>> My point is that I believe that a clean separation should be made >>>between global addresses and scoped addresses. We fully understand >>>how globals and link-locals work. All the others are still being >>>hashed out. If we make this break, the address architecture can >>>move along the standards track. The (great amount of) additional >>>work that needs to be done on scoped addresses can be carried out >>>under the scoped address architecture. >> >> >> actually I'd claim that we don't really understand how link-locals >> work, at least not from the applications viewpoint. but I enthusiastically >> support the idea of separating the work on globals from the work >> on scoped addresses. > >I believe we do have a good understanding on how link-locals >work with utility protocols (ICMP, ND, MLD, routing protocols). >That is why the LL are needed in the base addressing architecture. >As for LL and user apps, I can't speak authoratively on the subject. i believe we have some clues on application consideration to scoped addresses. we may need to document this: - for numeric representation, scoped address notation, like fe80::1%if0 is available. - name-to-address mapping is rather complicated. libc resolvers can sometimes deal with scoped address, assuming (1) the API is scope-capable (getaddrinfo/getnameinfo), and (2) the view of scope is the same, i.e. we don't cross node boundary (3) all data paths are scope-capable. for instance, /etc/hosts is ok. DNS/NIS is not ok due to (2) and (3). if server and client are on different machine view of scope is different so (2) is not satisfied. even if server is collocated with client DNS uses 128bit notation (AAAA) so scope info is lost/not handled so (3) is not satisfied. here are questions i can't really answer: - what is the exact relationship between link identifier and interface names/identifiers (API issue) for instance, KAME assumes one-by-one mapping and uses interface identifier as link identifier. but the assumption breaks if we consider configs like multiple interfaces connected to single ethernet broadcast domain - what defines a site there are theoretical definitions but operationally how? 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 Wed Oct 16 09:14:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GGEC29029867; Wed, 16 Oct 2002 09:14:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GGECk6029866; Wed, 16 Oct 2002 09:14:12 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GGE929029859 for ; Wed, 16 Oct 2002 09:14:09 -0700 (PDT) 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 g9GGEFMq014259 for ; Wed, 16 Oct 2002 09:14:15 -0700 (PDT) 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 JAA18892 for ; Wed, 16 Oct 2002 09:14:09 -0700 (PDT) From: juha.wiljakka@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 g9GGE8H25141 for ; Wed, 16 Oct 2002 19:14:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 16 Oct 2002 19:14:08 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 19:14:08 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPv6 node requirements - some comments x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 16 Oct 2002 19:14:08 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC352C@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 node requirements - some comments Thread-Index: AcJ1Lw2GVnGTrzIzThC3FCV5Hd5ZCQ== To: , X-OriginalArrivalTime: 16 Oct 2002 16:14:08.0188 (UTC) FILETIME=[0E3237C0:01C2752F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GGE929029860 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, it has been quite silent around "IPv6 node requirements" lately. http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-01.txt Here are some comments on it to hopefully activate the discussion again: - 1.2: There has been discussion on using the conformance groups. Somehow I would feel much more comfortable with the conventional MUST / SHOULD / MAY keywords. - 2.: Abbreviations list should be made more complete, i.e. adding PPP, ATM, FDDI, NBMA, etc. abbreviations mentioned in the document - 3.1.8: IMHO, RFC2529 is a transition mechanism and does not very well fit here... - 4.1.1: As RFC2460 is one of the most relevant IPv6 RFCs, I'm just wondering, whether so long descriptive text is actually needed in this document? Would just saying that RFC2460 is mandatory / MUST do the job? - 4.4 and 4._1_.1 Why making this subchapter, i.e. could ICMPv6 RFC just be mentioned in 4.4? - 4.5.5 and 5.3.1: Should we combine these and have DHCPv6 mentioned only in 4.5.5? - 5. Why are DNS and Transport Layers in the same chapter? => make separate chapters? - 5.2: DNS discovery is an important and missing thing here, I propose mentioning at least this mechanism here http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-06.txt - 6.: What should we do with the transition things in this document? Is this something we should totally leave for v6ops wg? As we all know, 4 design teams (unmanaged, enterprise, ISP and cellular) are working at the moment. - 7.: I think we should wait until the MIPv6 RFC has been completed to finalize this section. IMHO, at least things that are mandatory for all IPv6 nodes should be mentioned / actually specified here. Route Optimization requirements for all Correspondent Nodes may also be mentioned here. But what comes to Mobile Node or Home Agent functionality, maybe those do not belong to this "minimum IPv6 node requirements" document. Best Regards, -Juha W.- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 10:20:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GHKe29000134; Wed, 16 Oct 2002 10:20:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GHKedn000133; Wed, 16 Oct 2002 10:20:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GHKb29000125 for ; Wed, 16 Oct 2002 10:20:37 -0700 (PDT) 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 g9GHKgPG020131 for ; Wed, 16 Oct 2002 10:20:42 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05739 for ; Wed, 16 Oct 2002 10:20:37 -0700 (PDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 16 Oct 2002 10:20:36 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Oct 2002 10:20:36 -0700 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 16 Oct 2002 10:20:36 -0700 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: Implementation worries about default address selection Date: Wed, 16 Oct 2002 10:20:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implementation worries about default address selection Thread-Index: AcJ05ixjwKDhaUlxRo6qjC2R7w2jcwATlz3w From: "Richard Draves" To: "JINMEI Tatuya / ????" , "Pekka Savola" Cc: "Erik Nordmark" , X-OriginalArrivalTime: 16 Oct 2002 17:20:36.0646 (UTC) FILETIME=[57809C60:01C27538] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GHKb29000127 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Sorry I've been traveling and I'm just catching up on this thread.] As it happens my implementation does do some caching - the equivalent of a destination cache entry also caches the source address to use for that destination, if the application hasn't specified a source address. Section 8 (Implementation Considerations) discusses implementation issues that would affect the correctness of the implementation. It talks about caching from the point of view of what happens if you are working with stale information. I don't see the need for explicit advice to implementators about how to code a high-performance implementation. It would be hard to write such a section - the details of different implementations and their deployment environments vary widely. In his original email Pekka raised another couple issues - > 1. another issue struct me while re-reading: the draft > discusses source/destination address selection separately: > with S, select D from D_1, D_2, ..., D_n, or with D, select S > from S_1, S_2, ..., S_n. If I understood correctly a fairly > common case of S_1, S_2, ..., S_n *AND* D_1, D_1, ..., D_n > was not elaborated more (a brief mention in section 2?). I think section 6 is quite clear about this. For each destination address D, you select a source address Source(D) and you use Source(D) when sorting the destination addresses. > 2. IMO, I think sections 3.2 and 3.3 may be a bit ambiguous > wrt. mapped addresses and scopes. Is it supposed to say that > if I have configured '::ffff:10.0.0.1' on an interface (for > some reason..), treat it as global (per 3.3), but if I'm > communicating via IPv4 (and it was just added to destination > address selection as a mapped address ::ffff:10.0.0.1, treat > is as site-local (per 3.2))?!? This surely got me confused! When you are dealing with IPv4 addresses in section 6, you look at the IPv4 address's scope. Section 6 says The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. It does not say to calculate the scope of an IPv4 address by representing it as an IPv4-mapped address and then applying section 3.3. Instead section 3.2 says explicitly how you calculate the scope of an IPv4 address. Section 3.3 is saying that when you are calculating the scope of an IPv6 address, you don't need to recognize the various IPv6 address forms that have an embedded IPv4 address and extract the IPv4 address and look at that. Instead the RFC 2373 definition of the scope of an IPv6 address, based on the high bits of the IPv6 address, is correct. 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 Wed Oct 16 10:59:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GHx429000345; Wed, 16 Oct 2002 10:59:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GHx3Iu000344; Wed, 16 Oct 2002 10:59:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GHwx29000334 for ; Wed, 16 Oct 2002 10:58:59 -0700 (PDT) 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 g9GHx5Mq013272 for ; Wed, 16 Oct 2002 10:59:05 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03537 for ; Wed, 16 Oct 2002 11:59:00 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA25722 for ; Wed, 16 Oct 2002 10:58:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Oct 2002 13:59:59 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@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 have several technical and organizational comments regarding this document. The document states: "Thus, it is recommended to implement also other mechanisms for overriding this default, for example: manual configuration, L2 mechanisms and/or DHCPv6." I think that it should be required (a MUST) that nodes that implement this specification provide a method to override the default values manually. The document should also specify whether the default DNS addresses will or won't be considered part of the DNS server list when DNS server addresses are configured via other means. For example, if a host receives a single DNS server address via DHCP, will it fall-back to using these well-known addresses if the DNS server at the DCHP-configured address fails to respond? Listing anything as a "last resort" is problematic, because there may be something that comes along later that should only be used if this fails. Instead, I would like to see this document explicitly define how this mechanism does/doesn't interoperate with other mechanisms (DHCP, SLP, manual configuration). The document also states: "d) Having an "announcement" protocol that the DNS resolver could use to advertize the host route to the nearby router. Details of such a protocols are out of scope of this document, but something similar to [MLD] is possible." In my opinion, this section points out one major weakness with this approach. We _still_ need some way to configure the location of DNS servers in the network... Today, we do that on hosts (often using DHCP to provide the information, effectively moving the configuration to the DHCP server). This draft proposes moving that knowledge off of hosts and DHCP servers, and into the routing system, but it doesn't actually specify how the routing system will get the information. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:09:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GI9R29000420; Wed, 16 Oct 2002 11:09:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GI9R9P000419; Wed, 16 Oct 2002 11:09:27 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GI9O29000412 for ; Wed, 16 Oct 2002 11:09:24 -0700 (PDT) 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 g9GI9UMq016039 for ; Wed, 16 Oct 2002 11:09:30 -0700 (PDT) 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 MAA29782 for ; Wed, 16 Oct 2002 12:09:24 -0600 (MDT) Message-ID: <007801c2753e$f6353720$426015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Bound, Jim" , , "Pekka Savola" Cc: "Nick 'Sharkey' Moore" , References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953B@tayexc13.americas.cpqcorp.net> Subject: Re: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:07:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > Simply because of address spoof DOS we must at least permit DAD. The > cost is only at node-on. Now the timers and lifetimes administration > for a mobile network could be a problem but that is tunable. I believe > we are talking miliseconds. What we need are some tests. > I will ask our folks to test our handhelds for DAD timings. That'd be useful. > > But any implementation can turn anything it wants off for v6. We can > say MUST or SHOULD but users may or may not use it. > Yes. If the cost of DAD is too high (compared to the risk), and solutions to remedy the situation is also not as attractive, networks/architectures might choose to skip DAD, I'm afraid. > I am not comfortable changing DAD for anything here quite yet based on > the arguments on the "for" side at all. As far as I understand, people are not suggesting changing DAD, but instead developing an optimized version of it. Both versions should be able to co-exist, no interference. alper > > /jim > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 5:12 PM > To: alh-ietf@tndh.net; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > > Hi Tony, > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > I don't think we can consider all "handoffs" as 'make-before-break'. > There exists some link-layer technologies that allow this, but not all > have such capability. > > Completing DAD before handover requires either movement anticipation or > make-before-break, both of which are not widely applicable. Therefore > solving DAD latency for general case is a valid approach, imo. > > alper > > > > > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as > > > currently specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: ipng@sunroof.eng.sun.com > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > > > > > handovers working for IPv6 mobility is the long delay involved > > > > > in > > > > > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour in order to > > > > > minimize disruption in case of an address conflict (and maintain > > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > > and I've formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home 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 > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:11:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIBD29000443; Wed, 16 Oct 2002 11:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIBDHH000442; Wed, 16 Oct 2002 11:11:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIB929000435 for ; Wed, 16 Oct 2002 11:11:09 -0700 (PDT) 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 g9GIBFMq016545 for ; Wed, 16 Oct 2002 11:11:15 -0700 (PDT) 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 LAA18228 for ; Wed, 16 Oct 2002 11:11:10 -0700 (PDT) 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 LAA06580; Wed, 16 Oct 2002 11:11:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9GIB5A10368; Wed, 16 Oct 2002 11:11:05 -0700 X-mProtect: <200210161811> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlT3v6w; Wed, 16 Oct 2002 11:11:03 PDT Message-ID: <3DADABB8.950963A6@iprg.nokia.com> Date: Wed, 16 Oct 2002 11:11:04 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bound, Jim" CC: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953E@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jim, Layer 3 handover definitely can and does work. We have been showing smooth layer-3 handover for voice for almost two years now, even with conference demos and press releases, using Mobile IPv6. Improvements have been done for QoS and several other features which aren't the point of this note. Video is either done or doable depending on your definitions. The media and technology (Mobile IP and fast handovers) support it; some way of alleviating DAD delays is required for it to work. The market and the standardization process are another matter entirely. Research publications are yet another matter, but some papers have been published. Regards, Charlie P. "Bound, Jim" wrote: > > Alper, > > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? > > Thanks > /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 Oct 16 11:11:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIBl29000459; Wed, 16 Oct 2002 11:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIBlMl000458; Wed, 16 Oct 2002 11:11:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIBf29000445 for ; Wed, 16 Oct 2002 11:11:41 -0700 (PDT) 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 g9GIBlPG004850 for ; Wed, 16 Oct 2002 11:11:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12771 for ; Wed, 16 Oct 2002 12:11:42 -0600 (MDT) Message-ID: <007e01c2753f$492d7320$426015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Bound, Jim" , , "Pekka Savola" Cc: "Nick 'Sharkey' Moore" , References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953E@tayexc13.americas.cpqcorp.net> Subject: Re: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 11:10:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? You mean Mobile IPv6? It works. alper > > Thanks > /jim > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 5:43 PM > To: alh-ietf@tndh.net; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > > > True, but the term 'hand-off' implies a make-before-break process, > > > > else the MN is just establishing itself on a new link. Given it > has > > > > the opportunity to be aware of multiple links, it can > > > decide when to > > > > switch. I am arguing that it complete DAD 'before' it makes that > > > > decision, not after. > > > > > > I don't think we can consider all "handoffs" as > > > 'make-before-break'. There exists some link-layer > > > technologies that allow this, but not all have such capability. > > > > Then DAD latency should be the least of the concerns. > > Not really. For example 802.11b (link-layer) handover can take something > like 200ms, and DAD would take 1sec on that link. > People are already working on shrinking link-layer handover latency, and > some should do the same for DAD as well. > > > > > > > > > Completing DAD before handover requires either movement > > > anticipation or make-before-break, both of which are not > > > widely applicable. Therefore solving DAD latency for general > > > case is a valid approach, imo. > > > > My argument is that all MNs anticipate movement, and establish DAD > > before they really make the move. Yes this will generate some overhead > > > if the node doesn't move, but that is a minor cost in the grand scheme > > > of things. > > We cannot assume all MNs can "anticipate movement". Not all link-layers > have this capability. > > alper > > > > > > > Tony > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > Tony > > > > > > > > > -----Original Message----- > > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > > > To: Tony Hain > > > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > > > [...] it would seem the prudent thing for a MN to do is > > > > > establish DAD > > > > > > for all candidate prefixes well before it is ready to > > > start using > > > > > > them. [...] > > > > > > > > > > Isn't there a problem with how this could be done, as currently > > > > > specified? > > > > > > > > > > One can't perform DAD before being on the link. > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > > > 'Sharkey' Moore > > > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > > > To: ipng@sunroof.eng.sun.com > > > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > > > > > One of the big issues in getting low-latency handovers > > > > > > > working for IPv6 mobility is the long delay > > > involved > > > > > > > in > > > > > > > completing DAD. > > > > > > > > > > > > > > One option is to allow the Mobile Node to communicate > > > while the > > > > > > > address is still Tentative (optimistically assuming that DAD > > > > > > > will succeed), but to adjust its ND / SAA behaviour > > > in order to > > > > > > > minimize disruption in case of an address conflict > > > (and maintain > > > > > > > correct interoperation with > > > > > unmodified nodes). > > > > > > > > > > > > > > We've kicked the idea around a little on mobile-ip, and I've > > > > > > > > formalized my thoughts into an internet draft, > > > > > which should > > > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > > > > > I'd be interested in your opinions on the > > > draft, and its > > > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > > > > > > > cheers, > > > > > > > Nick > > > > > > > -- > > > > > > > Nick 'Sharkey' Moore > > > > > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > IETF IPng Working Group Mailing List > > > > > > > IPng Home 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 > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > -- > > > > > Pekka Savola "Tell me of difficulties > surmounted, > > > > > Netcore Oy not those you stumble over and > fall" > > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of > > > > > Swords > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:23:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GINE29000671; Wed, 16 Oct 2002 11:23:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GINE17000670; Wed, 16 Oct 2002 11:23:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GINA29000663 for ; Wed, 16 Oct 2002 11:23:10 -0700 (PDT) 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 g9GINGPG008460 for ; Wed, 16 Oct 2002 11:23:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23960 for ; Wed, 16 Oct 2002 12:23:09 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GIMwN15739; Wed, 16 Oct 2002 21:22:58 +0300 Date: Wed, 16 Oct 2002 21:22:58 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Very good comments; on one point.. On Wed, 16 Oct 2002, Margaret Wasserman wrote: > "d) Having an "announcement" protocol that the DNS resolver could > use to advertize the host route to the nearby router. Details of > such a protocols are out of scope of this document, but something > similar to [MLD] is possible." > > In my opinion, this section points out one major weakness with > this approach. We _still_ need some way to configure the location > of DNS servers in the network... Today, we do that on hosts (often > using DHCP to provide the information, effectively moving the > configuration to the DHCP server). This draft proposes moving > that knowledge off of hosts and DHCP servers, and into the routing > system, but it doesn't actually specify how the routing system > will get the information. Options a) - c) should be sufficient to describe how the routing system will get the information. Perhaps it should be reworded to be something like: d) Developing an "announcement" protocol [...] [...]. However, the three first mechanisms should cover the necessary techniques sufficiently for most cases. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:26:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIQY29000733; Wed, 16 Oct 2002 11:26:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIQYGU000732; Wed, 16 Oct 2002 11:26:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIQU29000722 for ; Wed, 16 Oct 2002 11:26:30 -0700 (PDT) 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 g9GIQaPG009467 for ; Wed, 16 Oct 2002 11:26:36 -0700 (PDT) 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 MAA24189 for ; Wed, 16 Oct 2002 12:26:30 -0600 (MDT) 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 LAA07963; Wed, 16 Oct 2002 11:26:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9GIQSs11909; Wed, 16 Oct 2002 11:26:28 -0700 X-mProtect: <200210161826> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRaNiyL; Wed, 16 Oct 2002 11:26:25 PDT Message-Id: <4.3.2.7.2.20021016094809.02a370c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Oct 2002 11:26:09 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-03.txt Pages : 7 Date : 2002-9-11 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. The w.g. last call will end on 30 October, 2002. Bob Hinden / Steve Deering / Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:30:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIUT29000827; Wed, 16 Oct 2002 11:30:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIUTME000826; Wed, 16 Oct 2002 11:30:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIUQ29000819 for ; Wed, 16 Oct 2002 11:30:26 -0700 (PDT) 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 g9GIUWMq022449 for ; Wed, 16 Oct 2002 11:30:32 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03357 for ; Wed, 16 Oct 2002 11:30:27 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA20418; Wed, 16 Oct 2002 11:29:22 -0700 (PDT) Message-Id: <5.1.0.14.2.20021016142728.02b1ab40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Oct 2002 14:31:16 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Options a) - c) should be sufficient to describe how the routing system >will get the information. The three points you mention all indicate that you would "run a routing protocol" to inject routes into the routing system. Are you just assuming that the routing protocol would be manual configured with the routing information needed for packets to the well-known addresses to reach the DNS servers? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:32:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIWY29000889; Wed, 16 Oct 2002 11:32:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIWY0p000888; Wed, 16 Oct 2002 11:32:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIWU29000881 for ; Wed, 16 Oct 2002 11:32:30 -0700 (PDT) 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 g9GIWaMq023223 for ; Wed, 16 Oct 2002 11:32:36 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25906 for ; Wed, 16 Oct 2002 12:32:31 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 726872EFF; Wed, 16 Oct 2002 14:32:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 14:32:30 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 14:32:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9560@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1P2l8wWu5ivWrSlG+zple7FTetAAAr5TQ From: "Bound, Jim" To: "Charles E. Perkins" Cc: , X-OriginalArrivalTime: 16 Oct 2002 18:32:30.0236 (UTC) FILETIME=[629A35C0:01C27542] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GIWV29000882 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, Test beds are good. But no one is going to use it till we make sure it works across many products. I would not put my shit on the line for anyones implementation of layer 3 such as a soldier or hospital emergency rescue team. Nor for IPv6 at this time. I would like to see specs for this and agreement on MIPv6 movement. We can't even get MIPv6 PS in the IETF. Thanks /jim -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Wednesday, October 16, 2002 1:11 PM To: Bound, Jim Cc: alh-ietf@tndh.net; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Hello Jim, Layer 3 handover definitely can and does work. We have been showing smooth layer-3 handover for voice for almost two years now, even with conference demos and press releases, using Mobile IPv6. Improvements have been done for QoS and several other features which aren't the point of this note. Video is either done or doable depending on your definitions. The media and technology (Mobile IP and fast handovers) support it; some way of alleviating DAD delays is required for it to work. The market and the standardization process are another matter entirely. Research publications are yet another matter, but some papers have been published. Regards, Charlie P. "Bound, Jim" wrote: > > Alper, > > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? > > Thanks > /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 Oct 16 11:33:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIXr29000927; Wed, 16 Oct 2002 11:33:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIXqJ3000926; Wed, 16 Oct 2002 11:33:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIXm29000919 for ; Wed, 16 Oct 2002 11:33:48 -0700 (PDT) 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 g9GIXsPG012309 for ; Wed, 16 Oct 2002 11:33:54 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29818 for ; Wed, 16 Oct 2002 12:33:48 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 34FB459BB; Wed, 16 Oct 2002 14:33:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Oct 2002 14:33:47 -0400 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: Optimistic DAD draft ... Date: Wed, 16 Oct 2002 14:33:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9561@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1P3UgoTkLX1hIQzGVh0a/ZX3z9gAAvT4Q From: "Bound, Jim" To: "Alper E. YEGIN" , , "Pekka Savola" Cc: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 16 Oct 2002 18:33:47.0892 (UTC) FILETIME=[90E39340:01C27542] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GIXn29000920 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How can mobile IPv6 in the market without at least PS and LMM is still a discussion which I believe is required and as you know I say use AAAv6 instead of overhead of Ipsec. Now if you mean we can move in the market as vendors without the IETF I agree but that has not happened yet. /jim -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, October 16, 2002 1:10 PM To: Bound, Jim; alh-ietf@tndh.net; Pekka Savola Cc: Nick 'Sharkey' Moore; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Jim, > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? You mean Mobile IPv6? It works. alper > > Thanks > /jim > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, October 15, 2002 5:43 PM > To: alh-ietf@tndh.net; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > > > > True, but the term 'hand-off' implies a make-before-break > > > > process, else the MN is just establishing itself on a new link. > > > > Given it > has > > > > the opportunity to be aware of multiple links, it can > > > decide when to > > > > switch. I am arguing that it complete DAD 'before' it makes that > > > > decision, not after. > > > > > > I don't think we can consider all "handoffs" as > > > 'make-before-break'. There exists some link-layer technologies > > > that allow this, but not all have such capability. > > > > Then DAD latency should be the least of the concerns. > > Not really. For example 802.11b (link-layer) handover can take > something like 200ms, and DAD would take 1sec on that link. People are > already working on shrinking link-layer handover latency, and some > should do the same for DAD as well. > > > > > > > > > Completing DAD before handover requires either movement > > > anticipation or make-before-break, both of which are not widely > > > applicable. Therefore solving DAD latency for general case is a > > > valid approach, imo. > > > > My argument is that all MNs anticipate movement, and establish DAD > > before they really make the move. Yes this will generate some overhead > > > if the node doesn't move, but that is a minor cost in the grand > > scheme > > > of things. > > We cannot assume all MNs can "anticipate movement". Not all > link-layers > have this capability. > > alper > > > > > > > Tony > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > Tony > > > > > > > > > -----Original Message----- > > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > > > To: Tony Hain > > > > > Cc: 'Nick 'Sharkey' Moore'; ipng@sunroof.eng.sun.com > > > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > > > [...] it would seem the prudent thing for a MN to do is > > > > > establish DAD > > > > > > for all candidate prefixes well before it is ready to > > > start using > > > > > > them. [...] > > > > > > > > > > Isn't there a problem with how this could be done, as > > > > > currently > > > > > specified? > > > > > > > > > > One can't perform DAD before being on the link. > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ipng@sunroof.eng.sun.com > > > > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Nick > > > > > > > 'Sharkey' Moore > > > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > > > To: ipng@sunroof.eng.sun.com > > > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > > > > > One of the big issues in getting low-latency handovers > > > > > > > working for IPv6 mobility is the long delay > > > involved > > > > > > > in > > > > > > > completing DAD. > > > > > > > > > > > > > > One option is to allow the Mobile Node to communicate > > > while the > > > > > > > address is still Tentative (optimistically assuming that > > > > > > > DAD will succeed), but to adjust its ND / SAA behaviour > > > in order to > > > > > > > minimize disruption in case of an address conflict > > > (and maintain > > > > > > > correct interoperation with > > > > > unmodified nodes). > > > > > > > > > > > > > > We've kicked the idea around a little on mobile-ip, and > > > > > > > I've > > > > > > > > formalized my thoughts into an internet draft, > > > > > which should > > > > > > > get published soon. In the meantime, you can find it at > > > > > > > > > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > > > > > I'd be interested in your opinions on the > > > draft, and its > > > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > > > > > > > cheers, > > > > > > > Nick > > > > > > > -- > > > > > > > Nick 'Sharkey' Moore > > > > > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > > > > > IETF IPng Working Group Mailing List > > > > > > > IPng Home 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 > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > > > > > > > > > > > > > > -- > > > > > Pekka Savola "Tell me of difficulties > surmounted, > > > > > Netcore Oy not those you stumble over and > fall" > > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of > > > > > Swords > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > -- > > > > -- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:37:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIbN29001034; Wed, 16 Oct 2002 11:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIbNhi001033; Wed, 16 Oct 2002 11:37:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIbK29001026 for ; Wed, 16 Oct 2002 11:37:20 -0700 (PDT) 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 g9GIbPPG013375 for ; Wed, 16 Oct 2002 11:37:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29934 for ; Wed, 16 Oct 2002 12:37:19 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GIbDE15898; Wed, 16 Oct 2002 21:37:13 +0300 Date: Wed, 16 Oct 2002 21:37:13 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <5.1.0.14.2.20021016142728.02b1ab40@mail.windriver.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, 16 Oct 2002, Margaret Wasserman wrote: > >Options a) - c) should be sufficient to describe how the routing system > >will get the information. > > The three points you mention all indicate that you would "run a > routing protocol" to inject routes into the routing system. Yep. Routing protocol has to be run anyway (static routes can be considered as a poor man's routing protocol and it works just as well) in the network to propagate information so this is natural. > Are > you just assuming that the routing protocol would be manual > configured with the routing information needed for packets to > the well-known addresses to reach the DNS servers? Yes. a) like 'ipv6 route fec0:000:0000:ffff::1 3ffe:ffff:ffff::1' on the first hop router(s). b) run a routing protocol, no biggie (e.g. BGP is ok and you can restrict the advertisement so even if the node is compromised, it can't jeopardize the whole routing system). c) run basically b) embedded in the process, or an equivalent (e.g. check the DNS server functionality periodically and kill the routing process if DNS server is dead) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:47:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIlH29001247; Wed, 16 Oct 2002 11:47:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIlG2i001246; Wed, 16 Oct 2002 11:47:16 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIlC29001239 for ; Wed, 16 Oct 2002 11:47:12 -0700 (PDT) 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 g9GIlHMq027691 for ; Wed, 16 Oct 2002 11:47:18 -0700 (PDT) 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 MAA09278 for ; Wed, 16 Oct 2002 12:47:12 -0600 (MDT) 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 LAA09292; Wed, 16 Oct 2002 11:47:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9GIlBp12823; Wed, 16 Oct 2002 11:47:11 -0700 X-mProtect: <200210161847> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdD1XcC2; Wed, 16 Oct 2002 11:47:08 PDT Message-ID: <3DADB42D.31FAB335@iprg.nokia.com> Date: Wed, 16 Oct 2002 11:47:09 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bound, Jim" CC: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9560@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jim, "Bound, Jim" wrote: > Test beds are good. But no one is going to use it till we make sure it > works across many products. Of course, people in general can't use it until it's productized. And, productization depends on standardization. However, I was responding to your sentence: > None of us working on this are even clear layer 3 handover will ever > work? I am providing the information that it DOES work. How long it takes to get to market will depend on things other than whether the technology is workable. In fact, the very things you pointed out. > I would not put my shit on the line for > anyones implementation of layer 3 such as a soldier or hospital > emergency rescue team. Nor for IPv6 at this time. Well, you could, but without products it would be hard. But productization and standardization have been hindered by factors which would not be important for the applications that you indicated. On the other hand, it's easier to write applications for products (vs. custom platforms) because it is easier to fund because there's more profit in it. > I would like to see specs for this and agreement on MIPv6 movement. We > can't even get MIPv6 PS in the IETF. We are currently busting our tails to respond to Working Group Last Call comments, and we are down to the end. You can see the progress by looking at our page of issues: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html Everyone knows it's been a long and contentious process. However, pessimism is not justified by current events. Regards, Charlie P. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Wednesday, October 16, 2002 1:11 PM > To: Bound, Jim > Cc: alh-ietf@tndh.net; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > Hello Jim, > > Layer 3 handover definitely can and does work. > We have been showing smooth layer-3 handover for > voice for almost two years now, even with conference > demos and press releases, using Mobile IPv6. > Improvements have been done for QoS and several > other features which aren't the point of this > note. Video is either done or doable depending > on your definitions. > > The media and technology (Mobile IP and fast > handovers) support it; some way of alleviating > DAD delays is required for it to work. The market > and the standardization process are another matter > entirely. Research publications are yet another > matter, but some papers have been published. > > Regards, > Charlie P. > > "Bound, Jim" wrote: > > > > Alper, > > > > None of us working on this are even clear layer 3 handover will ever > > work? Not sure if that matters does it? Are we talking about the > > future? > > > > Thanks > > /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 Oct 16 11:52:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIqj29001353; Wed, 16 Oct 2002 11:52:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIqiIj001351; Wed, 16 Oct 2002 11:52:44 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIqf29001344 for ; Wed, 16 Oct 2002 11:52:42 -0700 (PDT) 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 g9GIqlMq029420 for ; Wed, 16 Oct 2002 11:52:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11796 for ; Wed, 16 Oct 2002 12:52:42 -0600 (MDT) 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 LAA09710; Wed, 16 Oct 2002 11:52:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9GIqet21332; Wed, 16 Oct 2002 11:52:40 -0700 X-mProtect: <200210161852> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJkypvo; Wed, 16 Oct 2002 11:52:38 PDT Message-Id: <4.3.2.7.2.20021016115156.028ed2c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Oct 2002 11:52:21 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Comments on IPv6 Flow Label Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 w.g. chairs believe there are some important open issues that they would like to see the working group discuss as part of the working group last call on the "IPv6 Flow Label Specification" . The current draft allows flow labels to be used in ways that go beyond the consensus that was reached when the working group agreed to make this document a working group document. This consensus was that the flow label would be set by a source node to label a set of packets (with same source and destination addresses) that the source wanted to be treated as a flow. The flow label in this definition did not have any defined structure. The main application for this was to make it easier for other nodes to recognize flows without having to search to one or more headers to find the transport port numbers. The current draft has a number of features that go beyond this model and permit many other modes. Examples include: - Allowing for other standard specifications to define properties and/or structure of the flow label field. - A strong focus on the assignment of flow label via signaling protocols. - Allowing a specific flow label value to be assigned via a signaling protocol to identify flows with different source and destination addresses. The draft may be trying to accommodate uses of the flow label that were not agreed to by the working group. There are a number of other areas in the draft that need additional discussion and/or clarification. These include: - No default time out for the life time for specific flow label values. - No requirement that signaling mechanisms must include a lifetime when providing flow label setup information. - No default mechanisms if flow label values requested via a signaling mechanisms conflict with existing flow label values. - Security considerations need to discuss the impact of labeling flows of encrypted traffic. The chairs would like to see these issues discussed by the working group in the last call. Bob Hinden, Steve Deering, Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 11:59:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIxT29001502; Wed, 16 Oct 2002 11:59:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GIxTmb001501; Wed, 16 Oct 2002 11:59:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GIxQ29001494 for ; Wed, 16 Oct 2002 11:59:26 -0700 (PDT) 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 g9GIxWMq001086 for ; Wed, 16 Oct 2002 11:59:32 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17556; Wed, 16 Oct 2002 12:59:25 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GIxJu16083; Wed, 16 Oct 2002 21:59:19 +0300 Date: Wed, 16 Oct 2002 21:59:18 +0300 (EEST) From: Pekka Savola To: Richard Draves cc: JINMEI Tatuya / ???? , Erik Nordmark , Subject: RE: Implementation worries about default address selection 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 Wed, 16 Oct 2002, Richard Draves wrote: > As it happens my implementation does do some caching - the equivalent of > a destination cache entry also caches the source address to use for that > destination, if the application hasn't specified a source address. Yep, that seems like a sane approach. > Section 8 (Implementation Considerations) discusses implementation > issues that would affect the correctness of the implementation. It talks > about caching from the point of view of what happens if you are working > with stale information. Disagree: the section starts by examining the issues with destination address selection _only_, and never seems to move to discussing source address selection (or generic cache management). That is clearly inadequate IMO, and appears to be something just simply forgotten. > I don't see the need for explicit advice to > implementators about how to code a high-performance implementation. It > would be hard to write such a section - the details of different > implementations and their deployment environments vary widely. I agree. > In his original email Pekka raised another couple issues - > > > 1. another issue struct me while re-reading: the draft > > discusses source/destination address selection separately: > > with S, select D from D_1, D_2, ..., D_n, or with D, select S > > from S_1, S_2, ..., S_n. If I understood correctly a fairly > > common case of S_1, S_2, ..., S_n *AND* D_1, D_1, ..., D_n > > was not elaborated more (a brief mention in section 2?). > > I think section 6 is quite clear about this. For each destination > address D, you select a source address Source(D) and you use Source(D) > when sorting the destination addresses. I don't really understand the complexity of this but okay. (I wonder if this has been implemented in any libc w/ source available). > > 2. IMO, I think sections 3.2 and 3.3 may be a bit ambiguous > > wrt. mapped addresses and scopes. Is it supposed to say that > > if I have configured '::ffff:10.0.0.1' on an interface (for > > some reason..), treat it as global (per 3.3), but if I'm > > communicating via IPv4 (and it was just added to destination > > address selection as a mapped address ::ffff:10.0.0.1, treat > > is as site-local (per 3.2))?!? This surely got me confused! > > When you are dealing with IPv4 addresses in section 6, you look at the > IPv4 address's scope. Section 6 says > The algorithm sorts together both IPv6 and IPv4 addresses. To find > the attributes of an IPv4 address in the policy table, the IPv4 > address should be represented as an IPv4-mapped address. > It does not say to calculate the scope of an IPv4 address by > representing it as an IPv4-mapped address and then applying section 3.3. > Instead section 3.2 says explicitly how you calculate the scope of an > IPv4 address. > > Section 3.3 is saying that when you are calculating the scope of an IPv6 > address, you don't need to recognize the various IPv6 address forms that > have an embedded IPv4 address and extract the IPv4 address and look at > that. Instead the RFC 2373 definition of the scope of an IPv6 address, > based on the high bits of the IPv6 address, is correct. This is clarifies this a bit, but I believe there should an extra section in either 3.2 or 3.3 that spells out the difference explicitly, like adding something like the following in 3.2, before the last paragraph: It should be noted that only real IPv4 addresses, used in the destination address selection, and represented as IPv4-mapped addresses may have a different scope than global; other cases are described in the section below. This difference also worries me a bit and I wonder if there could be problems with tthis distinction. What if node has mapped addresses configured (for some reason), or DNS returns both 1.2.3.4 and ::ffff:1.2.3.4. You probably convert the IPv4 address to a mapped address but you need to add some bitflag to check which of them was "real". btw. there is typo around 'lookup' in section 3.2 line 5, I believe. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 12:45:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GJje29001849; Wed, 16 Oct 2002 12:45:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GJjerM001848; Wed, 16 Oct 2002 12:45:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GJja29001841 for ; Wed, 16 Oct 2002 12:45:36 -0700 (PDT) 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 g9GJjgPG001714 for ; Wed, 16 Oct 2002 12:45:42 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21103 for ; Wed, 16 Oct 2002 13:45:36 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9GJjY019495; Wed, 16 Oct 2002 15:45:34 -0400 (EDT) Message-Id: <200210161945.g9GJjY019495@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Wed, 16 Oct 2002 10:49:25 EDT.") <3DAD7C75.3030603@nc.rr.com> Date: Wed, 16 Oct 2002 15:45:34 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > actually I'd claim that we don't really understand how link-locals > > work, at least not from the applications viewpoint. but I enthusiastically > > support the idea of separating the work on globals from the work > > on scoped addresses. > > I believe we do have a good understanding on how link-locals > work with utility protocols (ICMP, ND, MLD, routing protocols). > That is why the LL are needed in the base addressing architecture. agree with this much. I think it's much harder to justify SL. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 12:46:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GJk029001859; Wed, 16 Oct 2002 12:46:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GJk0cD001858; Wed, 16 Oct 2002 12:46:00 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GJjt29001851 for ; Wed, 16 Oct 2002 12:45:55 -0700 (PDT) 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 g9GJk0Mq017217 for ; Wed, 16 Oct 2002 12:46:01 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20416 for ; Wed, 16 Oct 2002 13:45:55 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9GJiY019177; Wed, 16 Oct 2002 15:44:34 -0400 (EDT) Message-Id: <200210161944.g9GJiY019177@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Brian Haberman , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Thu, 17 Oct 2002 01:03:30 +0900.") <20021016160330.BAA744B25@coconut.itojun.org> Date: Wed, 16 Oct 2002 15:44:34 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i believe we have some clues on application consideration to scoped addresses. I don't get the sense that we have consensus on this, because some people seem to think that scoped addresses are appropriate for use by general-purpose apps. for instance, there's really no way that an application can effectively use a scoped address in a referral to another host, since the app has no idea whether the host that uses the referral has access to the same scope as the party providing the referral. name-to-address mapping is only one instance of this problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 13:13:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GKDq29002064; Wed, 16 Oct 2002 13:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GKDpXT002063; Wed, 16 Oct 2002 13:13:51 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GKDm29002056 for ; Wed, 16 Oct 2002 13:13:48 -0700 (PDT) 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 g9GKDsMq023913 for ; Wed, 16 Oct 2002 13:13:54 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07957 for ; Wed, 16 Oct 2002 14:13:48 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 16 Oct 2002 13:13:47 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , Cc: "'Brian Haberman'" , Subject: RE: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt Date: Wed, 16 Oct 2002 13:13:36 -0700 Message-ID: <007701c27550$82e2cb90$011aa8c0@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.3416 Importance: Normal In-reply-to: <200210161944.g9GJiY019177@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9GKDm29002057 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > I don't get the sense that we have consensus on this, because > some people seem to think that scoped addresses are > appropriate for use by general-purpose apps. > > for instance, there's really no way that an application can > effectively use > a scoped address in a referral to another host, since the app > has no idea > whether the host that uses the referral has access to the > same scope as > the party providing the referral. name-to-address mapping is > only one instance of this problem. An implementation note which identifies the need for any multi-party apps to have a scope determination mechanism before using SL is appropriate. Claiming SL is something that applications can't effectively use is a bit over the top. For a simple 2 party app (like sending a file to my printer), SL is a very appropriate addressing mechanism. If I don't want the world to connect to my printers, it is much easier to filter FEC0::/16 at the border than it is to list every printer in an access control list. A multi-party app developer should be happy there is a specific range of addresses set aside for SL. Without that it becomes a guessing game as to which addresses might work or not. With SL, the multi-party app can clearly state that those will not be used, so the environment becomes much clearer. 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 Wed Oct 16 13:49:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GKn329002330; Wed, 16 Oct 2002 13:49:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GKn3GZ002329; Wed, 16 Oct 2002 13:49:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GKmx29002322 for ; Wed, 16 Oct 2002 13:48:59 -0700 (PDT) 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 g9GKn5Mq002443 for ; Wed, 16 Oct 2002 13:49:05 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00795 for ; Wed, 16 Oct 2002 13:48:59 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9GKlY019961; Wed, 16 Oct 2002 16:47:39 -0400 (EDT) Message-Id: <200210162047.g9GKlY019961@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , itojun@iijlab.net, "'Brian Haberman'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Wed, 16 Oct 2002 13:13:36 PDT.") <007701c27550$82e2cb90$011aa8c0@eagleswings> Date: Wed, 16 Oct 2002 16:47:34 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > An implementation note which identifies the need for any multi-party > apps to have a scope determination mechanism before using SL is > appropriate. no, I'm sorry. It's not. it's insane. look, it's a separation of function argument. the network's job is to do "best effort delivery" SO THE APPLICATION DOESN'T HAVE TO. if you expect applications to do routing and address selection and to know about network topology not only on the local network but from the point of view of distant peers just in order to get the packets delivered, why don't we just dispense with routing protocols entirely? > Claiming SL is something that applications can't > effectively use is a bit over the top. For a simple 2 party app (like > sending a file to my printer), SL is a very appropriate addressing > mechanism. If I don't want the world to connect to my printers, it is > much easier to filter FEC0::/16 at the border than it is to list every > printer in an access control list. that's the same kind of bogus claim that's being made by the zeroconf folks for v4 LL addressing. > A multi-party app developer should be happy there is a specific range of > addresses set aside for SL. Without that it becomes a guessing game as > to which addresses might work or not. it's a guessing game anyway if sites think that SL addresses can be used as a substitute for routable addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 15:24:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMOH29002693; Wed, 16 Oct 2002 15:24:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GMOHMQ002692; Wed, 16 Oct 2002 15:24:17 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMOE29002685 for ; Wed, 16 Oct 2002 15:24:14 -0700 (PDT) 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 g9GMOJMq028055 for ; Wed, 16 Oct 2002 15:24:20 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21097 for ; Wed, 16 Oct 2002 16:24:12 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 8D4A1146D6; Thu, 17 Oct 2002 08:23:58 +1000 (EST) Date: Thu, 17 Oct 2002 08:23:56 +1000 From: "Nick 'Sharkey' Moore" To: "Bound, Jim" Cc: Tony Hain , "Charles E. Perkins" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021017082355.A1885@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953C@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953C@tayexc13.americas.cpqcorp.net>; from Jim.Bound@hp.com on Wed, Oct 16, 2002 at 11:15:50AM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Oct 16, 2002 at 11:15:50AM -0400, Bound, Jim wrote: > [Nick 'Sharkey' Moore wrote:] > > 1000ms is a long time by anyone's standards! > > I simply cannot believe it is 1000 ms. Like I said lets get some > empircal data. I was referring to the DAD delay, eg: RETRANS_TIMER from RFC 2461. We could obviously just reduce the RETRANS_TIMER value, but for real-time services we'd have to ask ourselves "How long is too long for real-time? How short is too short for reliable collision detection?" -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 15:34:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMYA29002764; Wed, 16 Oct 2002 15:34:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GMYABp002763; Wed, 16 Oct 2002 15:34:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMY729002756 for ; Wed, 16 Oct 2002 15:34:07 -0700 (PDT) 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 g9GMY8PG016191 for ; Wed, 16 Oct 2002 15:34:08 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01799 for ; Wed, 16 Oct 2002 16:34:01 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 8A76E146DA; Thu, 17 Oct 2002 08:33:49 +1000 (EST) Date: Thu, 17 Oct 2002 08:33:47 +1000 From: "Nick 'Sharkey' Moore" To: "Alper E. YEGIN" Cc: "Bound, Jim" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021017083346.B1885@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953B@tayexc13.americas.cpqcorp.net> <007801c2753e$f6353720$426015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007801c2753e$f6353720$426015ac@AlperVAIO>; from alper@docomolabs-usa.com on Wed, Oct 16, 2002 at 11:07:55AM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Oct 16, 2002 at 11:07:55AM -0700, Alper E. YEGIN wrote: > > As far as I understand, people are not suggesting changing DAD, but instead > developing an optimized version of it. Both versions should be able > to co-exist, no interference. That's exactly right, Alper. My reason for using the 'Override' bit rather than a dedicated 'Tentative' bit (like earlier Optimistic drafts) was because existing nodes (assuming they implement 2461/2462 correctly) will understand it already. There's a couple of odd cases involving an address collision and a new connection to that address within a very small time window, but they're quite improbable and easily recoverable by standard NUD without too much fuss. I'm in the process of coding the draft up as a patch to Linux, and crippling the random generator to induce collisions, so we'll be able to get some real test results soon too. If anyone has any questions about the draft details, ask away! -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 15:45:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMjr29002873; Wed, 16 Oct 2002 15:45:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9GMjrhm002872; Wed, 16 Oct 2002 15:45:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9GMjo29002865 for ; Wed, 16 Oct 2002 15:45:50 -0700 (PDT) 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 g9GMjtPG018873 for ; Wed, 16 Oct 2002 15:45:55 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03810 for ; Wed, 16 Oct 2002 16:45:49 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id C971A146D2; Thu, 17 Oct 2002 08:45:39 +1000 (EST) Date: Thu, 17 Oct 2002 08:45:38 +1000 From: "Nick 'Sharkey' Moore" To: "Bound, Jim" Cc: "Alper E. YEGIN" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021017084537.C1885@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953E@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953E@tayexc13.americas.cpqcorp.net>; from Jim.Bound@hp.com on Wed, Oct 16, 2002 at 11:18:52AM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Oct 16, 2002 at 11:18:52AM -0400, Bound, Jim wrote: > Alper, > > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? We're pretty clear on this: we've tested it. The significant delays are: * 100-1000ms Network RTT for binding updates (FIX: hmipv6, etc) * 1000ms DAD timeout delay (FIX: Optimistic DAD, etc) * 200ms+ L2 handover delay (argh!) ----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 17:40:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H0ej29003375; Wed, 16 Oct 2002 17:40:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H0ejsR003374; Wed, 16 Oct 2002 17:40:45 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H0ef29003367 for ; Wed, 16 Oct 2002 17:40:41 -0700 (PDT) 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 g9H0elMq002523 for ; Wed, 16 Oct 2002 17:40:47 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03704 for ; Wed, 16 Oct 2002 18:40:41 -0600 (MDT) Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9H0dUcl015138 for ; Thu, 17 Oct 2002 02:39:30 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA19944 for ipng@sunroof.eng.sun.com; Thu, 17 Oct 2002 01:40:40 +0100 (BST) Date: Thu, 17 Oct 2002 01:40:40 +0100 From: Derek Fawcus To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Message-ID: <20021017014040.B8106@edi-view1.cisco.com> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com>; from hinden@iprg.nokia.com on Fri, Oct 11, 2002 at 02:13:45PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this draft is a poor idea, and that if people want an autoconfig mechanism, then something along the lines of draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible. Mind one would still have to configure the router to generate the above option in a RA, but then something would always have to be configured somewhere. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 18:00:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H10R29003562; Wed, 16 Oct 2002 18:00:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H10RXt003561; Wed, 16 Oct 2002 18:00:27 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H10N29003554 for ; Wed, 16 Oct 2002 18:00:23 -0700 (PDT) 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 g9H10TMq007736 for ; Wed, 16 Oct 2002 18:00:29 -0700 (PDT) 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 SAA24386 for ; Wed, 16 Oct 2002 18:00:23 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 138764B25; Thu, 17 Oct 2002 10:00:18 +0900 (JST) To: Keith Moore Cc: Brian Haberman , ipng@sunroof.eng.sun.com In-reply-to: moore's message of Wed, 16 Oct 2002 15:44:34 -0400. <200210161944.g9GJiY019177@astro.cs.utk.edu> 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: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt From: itojun@iijlab.net Date: Thu, 17 Oct 2002 10:00:18 +0900 Message-Id: <20021017010018.138764B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> i believe we have some clues on application consideration to scoped >> addresses. > >I don't get the sense that we have consensus on this, because some >people seem to think that scoped addresses are appropriate for use by >general-purpose apps. > >for instance, there's really no way that an application can effectively use >a scoped address in a referral to another host, since the app has no idea >whether the host that uses the referral has access to the same scope as >the party providing the referral. name-to-address mapping is only one >instance of this problem. agreed. you can't pass around scoped address across nodes (in general) as the view of the scope differs between nodes. i have clearer idea on link-locals, but i have almost no solutions against site-locals. there are security issues associated with it (attacking other company's inside machine using routing header w/ site-local address, and such...). scoped address complicates address in referral. to give a concrete example, to support ftp session using scoped address, KAME ftpd behaves like below to deal with "EPRT" command: - control connection is using TCP over link-local address, between fe80::2 (ftpd) and fe80::1 (client). ftpd is seeing some scope identification in sockaddr_in6 returned from getpeername/ getsockname. - ftpd receives an EPRT command, like "EPRT |2|fe80::1|9999|" from the client (note that there's no scope identification in the FTP command stream) - ftpd fills sockaddr_in6 with fe80::1 - ftpd copies sin6_scope_id from the sockaddr_in6 for control connection, ASSUMING that the address specified by EPRT is in the same scope as the control connection. these days the assumption holds as EPRT to thirdparty address is disallowed, however, it is not really a sane assumption to make. - ftpd makes data connection to fe80::1%, which (hopefully) reaches the client. 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 Wed Oct 16 18:49:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H1nF29003688; Wed, 16 Oct 2002 18:49:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H1nFmF003687; Wed, 16 Oct 2002 18:49:15 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H1nC29003680 for ; Wed, 16 Oct 2002 18:49:12 -0700 (PDT) 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 g9H1nIMq021184 for ; Wed, 16 Oct 2002 18:49:18 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15123 for ; Wed, 16 Oct 2002 19:49:12 -0600 (MDT) From: Jonne.Soininen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H1nuM06712 for ; Wed, 16 Oct 2002 20:49:57 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 20:49:12 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 20:49:11 -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: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Date: Wed, 16 Oct 2002 18:49:10 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDAFE@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJ1dqqKOBDmzmMmR4KqpH8ftR/Y+gABfCaA To: , X-OriginalArrivalTime: 17 Oct 2002 01:49:11.0997 (UTC) FILETIME=[6411A6D0:01C2757F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9H1nC29003681 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everybody, after reading all the previous mails about this topic, I totally agree that the proposed DNS discovery is not a perfect solution. However, it is *a* solution that works. I believe it is easy to miss the main point: We currently do not have any mechanisms to configure a IPv6 host with the DNS resolver/server address - except of course by manual configuration. I am sure that if we wait a few years more, and keep working on this issue open we will find a better or at least more politically correct solution. The problem is that it does not solve our problem now. The currently proposed DNS discovery solution is simple, it does not break anything, and it works. Let's wrap it up, and have at least a solution. (And actually a backwards compatible solution, if a host supports manual configuration! ;) It might not be the perfect solution, but it works! Cheers, Jonne. > -----Original Message----- > From: ext Derek Fawcus [mailto:dfawcus@cisco.com] > Sent: Wednesday, October 16, 2002 5:41 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast > addresses for DNS resolver" > > > > I think this draft is a poor idea, and that if people want an > autoconfig mechanism, then something along the lines of > draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible. > > Mind one would still have to configure the router to generate the > above option in a RA, but then something would always have to be > configured somewhere. > > DF > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 19:31:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H2V229004137; Wed, 16 Oct 2002 19:31:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H2V2D1004136; Wed, 16 Oct 2002 19:31:02 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H2Uv29004129 for ; Wed, 16 Oct 2002 19:30:58 -0700 (PDT) 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 g9H2V3Mq004639 for ; Wed, 16 Oct 2002 19:31:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18942 for ; Wed, 16 Oct 2002 20:30:55 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:e80f:f93c:85be:9214]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9H2UWt72790; Thu, 17 Oct 2002 11:30:32 +0900 (JST) Date: Thu, 17 Oct 2002 11:31:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@iijlab.net Cc: Keith Moore , Brian Haberman , ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <20021017010018.138764B25@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20021017010018.138764B25@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 17 Oct 2002 10:00:18 +0900, >>>>> itojun@iijlab.net said: >> I don't get the sense that we have consensus on this, because some >> people seem to think that scoped addresses are appropriate for use by >> general-purpose apps. >> >> for instance, there's really no way that an application can effectively use >> a scoped address in a referral to another host, since the app has no idea >> whether the host that uses the referral has access to the same scope as >> the party providing the referral. name-to-address mapping is only one >> instance of this problem. > agreed. you can't pass around scoped address across nodes (in general) > as the view of the scope differs between nodes. i have clearer idea > on link-locals, but i have almost no solutions against site-locals. > there are security issues associated with it (attacking other company's > inside machine using routing header w/ site-local address, and such...). A tiny clarification (which is not directly related to the topic): the attacker can't go inside the other sites using a routing header, as long as the site border router is fully compliant to section 9 of draft-ietf-ipngwg-scoping-arch-04.txt. (Or perhaps you're assuming the existence of a non-compliant border router.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 23:07:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H67c29004558; Wed, 16 Oct 2002 23:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H67cuW004557; Wed, 16 Oct 2002 23:07:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H67Y29004550 for ; Wed, 16 Oct 2002 23:07:34 -0700 (PDT) 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 g9H67ePG018023 for ; Wed, 16 Oct 2002 23:07:41 -0700 (PDT) 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 XAA29933 for ; Wed, 16 Oct 2002 23:07:35 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E2DE45A8A; Thu, 17 Oct 2002 02:07:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Oct 2002 02:07:34 -0400 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: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 02:07:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1RHN6JBM/AIBsQna4Jyc0r+/uvQAXoqDQ From: "Bound, Jim" To: "Charles E. Perkins" Cc: X-OriginalArrivalTime: 17 Oct 2002 06:07:34.0751 (UTC) FILETIME=[7C6E2EF0:01C275A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9H67Z29004551 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, Yes clarify for the future. I am a PRODUCT engineer not research. I only care when it gets close to product. Clearly test beds are different. Pessimistic. Excuse me but I see nothing optimistic because I have heard it all to often. So don't even give me that at all. I do think its closer though and yes I am tracking it as painful as I find it. As far as custom platforms. That might be true but at times the market won't wait. That will happen very soon and new specs will show up that work from the market. Regards, /jim -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Wednesday, October 16, 2002 2:47 PM To: Bound, Jim Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Hello Jim, "Bound, Jim" wrote: > Test beds are good. But no one is going to use it till we make sure it > works across many products. Of course, people in general can't use it until it's productized. And, productization depends on standardization. However, I was responding to your sentence: > None of us working on this are even clear layer 3 handover will ever > work? I am providing the information that it DOES work. How long it takes to get to market will depend on things other than whether the technology is workable. In fact, the very things you pointed out. > I would not put my shit on the line for > anyones implementation of layer 3 such as a soldier or hospital > emergency rescue team. Nor for IPv6 at this time. Well, you could, but without products it would be hard. But productization and standardization have been hindered by factors which would not be important for the applications that you indicated. On the other hand, it's easier to write applications for products (vs. custom platforms) because it is easier to fund because there's more profit in it. > I would like to see specs for this and agreement on MIPv6 movement. We > can't even get MIPv6 PS in the IETF. We are currently busting our tails to respond to Working Group Last Call comments, and we are down to the end. You can see the progress by looking at our page of issues: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html Everyone knows it's been a long and contentious process. However, pessimism is not justified by current events. Regards, Charlie P. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Wednesday, October 16, 2002 1:11 PM > To: Bound, Jim > Cc: alh-ietf@tndh.net; ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > Hello Jim, > > Layer 3 handover definitely can and does work. > We have been showing smooth layer-3 handover for > voice for almost two years now, even with conference > demos and press releases, using Mobile IPv6. > Improvements have been done for QoS and several > other features which aren't the point of this > note. Video is either done or doable depending > on your definitions. > > The media and technology (Mobile IP and fast > handovers) support it; some way of alleviating > DAD delays is required for it to work. The market > and the standardization process are another matter > entirely. Research publications are yet another > matter, but some papers have been published. > > Regards, > Charlie P. > > "Bound, Jim" wrote: > > > > Alper, > > > > None of us working on this are even clear layer 3 handover will ever > > work? Not sure if that matters does it? Are we talking about the > > future? > > > > Thanks > > /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 Oct 16 23:28:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H6SS29004662; Wed, 16 Oct 2002 23:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H6SSHH004661; Wed, 16 Oct 2002 23:28:28 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H6SO29004654 for ; Wed, 16 Oct 2002 23:28:24 -0700 (PDT) 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 g9H6SUMq017975 for ; Wed, 16 Oct 2002 23:28:30 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26445 for ; Thu, 17 Oct 2002 00:28:25 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B1F602EB9; Thu, 17 Oct 2002 02:28:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Oct 2002 02:28:24 -0400 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: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 02:28:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE956F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1Ys0GqeMkmFvXQ0ep0tLa6RVp0wAQ4SGg From: "Bound, Jim" To: "Nick 'Sharkey' Moore" Cc: "Tony Hain" , "Charles E. Perkins" , "Pekka Savola" , X-OriginalArrivalTime: 17 Oct 2002 06:28:24.0314 (UTC) FILETIME=[653A5DA0:01C275A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9H6SP29004655 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick, 100% agree. /jim -----Original Message----- From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] Sent: Wednesday, October 16, 2002 6:24 PM To: Bound, Jim Cc: Tony Hain; Charles E. Perkins; Pekka Savola; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... On Wed, Oct 16, 2002 at 11:15:50AM -0400, Bound, Jim wrote: > [Nick 'Sharkey' Moore wrote:] > > 1000ms is a long time by anyone's standards! > > I simply cannot believe it is 1000 ms. Like I said lets get some > empircal data. I was referring to the DAD delay, eg: RETRANS_TIMER from RFC 2461. We could obviously just reduce the RETRANS_TIMER value, but for real-time services we'd have to ask ourselves "How long is too long for real-time? How short is too short for reliable collision detection?" -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 16 23:35:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H6Z329004713; Wed, 16 Oct 2002 23:35:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H6Z3H3004712; Wed, 16 Oct 2002 23:35:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H6Z029004705 for ; Wed, 16 Oct 2002 23:35:00 -0700 (PDT) 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 g9H6Z6Mq018972 for ; Wed, 16 Oct 2002 23:35:06 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14112 for ; Thu, 17 Oct 2002 00:35:01 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 95A595AC3; Thu, 17 Oct 2002 02:35:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Oct 2002 02:35:00 -0400 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: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 02:34:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E9@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1ZcWJ9wrZGrWdQeWvrx4FKeSW/gAQQ27A From: "Bound, Jim" To: "Nick 'Sharkey' Moore" Cc: "Alper E. YEGIN" , , "Pekka Savola" , X-OriginalArrivalTime: 17 Oct 2002 06:35:00.0455 (UTC) FILETIME=[5158AF70:01C275A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9H6Z029004706 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick, Have you tested hmipv6 to the scale that mobility operator working with ISPs can cover the entire metropolis of L.A.? If your saying these tests can support moving a draft to PS I agree. But I would have agreed to moving hpmipv6 to PS last year. No one has deployed layer 3 in production environment I am aware of? Nor would I trust it yet simply because of this mail discussion. I will do technical detailed implementation analysis of James's draft and have asked mobile node comrades to test it. But I am tired of chasing ghosts in the IETF but I will yet one more time. Thanks /jim -----Original Message----- From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] Sent: Wednesday, October 16, 2002 6:46 PM To: Bound, Jim Cc: Alper E. YEGIN; alh-ietf@tndh.net; Pekka Savola; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... On Wed, Oct 16, 2002 at 11:18:52AM -0400, Bound, Jim wrote: > Alper, > > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? We're pretty clear on this: we've tested it. The significant delays are: * 100-1000ms Network RTT for binding updates (FIX: hmipv6, etc) * 1000ms DAD timeout delay (FIX: Optimistic DAD, etc) * 200ms+ L2 handover delay (argh!) ----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 00:45:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H7j929005008; Thu, 17 Oct 2002 00:45:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H7j8Yn005007; Thu, 17 Oct 2002 00:45:08 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H7j529005000 for ; Thu, 17 Oct 2002 00:45:05 -0700 (PDT) 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 g9H7jBMq001577 for ; Thu, 17 Oct 2002 00:45:11 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA16322 for ; Thu, 17 Oct 2002 01:45:04 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id C7455146D2; Thu, 17 Oct 2002 17:44:58 +1000 (EST) Date: Thu, 17 Oct 2002 17:44:57 +1000 From: "Nick 'Sharkey' Moore" To: "Bound, Jim" Cc: "Alper E. YEGIN" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021017174457.C3569@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E9@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E9@tayexc13.americas.cpqcorp.net>; from Jim.Bound@hp.com on Thu, Oct 17, 2002 at 02:34:59AM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 17, 2002 at 02:34:59AM -0400, Bound, Jim wrote: > From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] > > > Bound, Jim wrote: > > > > > > None of us working on this are even clear layer 3 handover will ever > > > work? Not sure if that matters does it? Are we talking about the > > > future? > > > We're pretty clear on this: we've tested it. > > Have you tested hmipv6 to the scale that mobility operator working with > ISPs can cover the entire metropolis of L.A.? To clarify: we've been doing some work to identify and isolate the causes of L3 handover delays, and they each seem solvable by one means or another. For example, hmipv6 offers one possible way of eliminating the RTT delay caused by sending BUs. In its current form, it probably isn't scalable to that level, but sadly I don't have a megapolis to test it with -- I'm a research engineer not a product engineer :-) Actually, JinHyeock reminded me that I'd forgotten to mention the Movement Detection Delay ... we've been tackling that with inter-layer signalling to prompt router solicitations. > No one has deployed layer 3 in production environment I am aware of? > Nor would I trust it yet simply because of this mail discussion. Ummm ... I hope it isn't my Optimism which has caused your concerns ... although if you've got technical comments or concerns re: my draft I'd love to hear them. It is, after all, a work in progress. The Optimistic DAD thing comes about because I thought the FH stuff was getting a bit theoretical and I felt that a set of small, easily implemented patches, one per cause of L3 handover delay, would be a good way to move forward in the short term. cheers, -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 02:24:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9O329005426; Thu, 17 Oct 2002 02:24:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H9O2We005425; Thu, 17 Oct 2002 02:24:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9Nw29005415 for ; Thu, 17 Oct 2002 02:23:58 -0700 (PDT) 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 g9H9O4PG011426 for ; Thu, 17 Oct 2002 02:24:05 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00431 for ; Thu, 17 Oct 2002 02:23:59 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9H9NWQ1021631; Thu, 17 Oct 2002 11:23:32 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Oct 2002 11:23:32 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B7C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Nick 'Sharkey' Moore'" , "Bound, Jim" Cc: "Alper E. YEGIN" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: RE: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 11:23:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To clarify: we've been doing some work to identify and isolate > the causes of L3 handover delays, and they each seem solvable > by one means or another. > > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current form, it probably > isn't scalable to that level, => Why not? I think it is scalable to that level simply because you can plug more anchor points as you see fit. it's as scalable as HAs are in MIPv6. > > Actually, JinHyeock reminded me that I'd forgotten to mention > the Movement Detection Delay ... we've been tackling that > with inter-layer signalling to prompt router solicitations. => What you're doing (optimistic DAD) can be combined with Fast Handovers to completely eliminate movement detection delay. > The Optimistic DAD thing comes about because I thought > the FH stuff was getting a bit theoretical and I felt that a > set of small, easily implemented patches, one per cause of > L3 handover delay, would be a good way to move forward in the > short term. => My very initial effort (with Karim) with Fast handovers was aimed at: anticipation + optimistic DAD + HMIPv6. I still think this is the simplest solution and will achieve excellent results. We already have some basic simulations (not to the level that Jim is asking for) that prove this and more to come. Hesham > > cheers, > -----Nick > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 02:43:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9hQ29005617; Thu, 17 Oct 2002 02:43:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H9hQwD005616; Thu, 17 Oct 2002 02:43:26 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9hM29005606 for ; Thu, 17 Oct 2002 02:43:22 -0700 (PDT) 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 g9H9hTMq014807 for ; Thu, 17 Oct 2002 02:43:29 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05164 for ; Thu, 17 Oct 2002 03:43:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9H9hM722884 for ; Thu, 17 Oct 2002 12:43:22 +0300 Date: Thu, 17 Oct 2002 12:43:22 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@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 On Fri, 11 Oct 2002, Bob Hinden wrote: I must chime in to say I dislike this approach a bit, but it could be salvageable. (Though, I must admit I like an option in RA's more..) Most of all, I dislike using *3* well known site local addresses. One should suffice just fine. Remember that this mechanism, at least in my eyes, is intended for *bootstrapping* only. After there is something that works, one could use some other mechanism (e.g. a DNS lookup :-) to discover *real* DNS server addresses and ignore the site local. It seems to me that _3_ addresses just triples delays (5-10 seconds each, per DNS lookup?) if none of those have been configured in the site. In addition, I greatly dislike section 5.2, that is DNS forwarding between sites. If we have to implement site-border router behaviour, let's *NOT* require it in every cheapo 50$ DSL router. btw, in introduction: s/usefull/useful/, s/moble/mobile/; in section 3: s/as DNS resolver/as DNS resolvers/. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 02:54:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9sm29005683; Thu, 17 Oct 2002 02:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9H9smxr005682; Thu, 17 Oct 2002 02:54:48 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9H9sj29005675 for ; Thu, 17 Oct 2002 02:54:45 -0700 (PDT) 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 g9H9sqMq016077 for ; Thu, 17 Oct 2002 02:54:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26572 for ; Thu, 17 Oct 2002 03:54:46 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9H9sYU23026; Thu, 17 Oct 2002 12:54:34 +0300 Date: Thu, 17 Oct 2002 12:54:34 +0300 (EEST) From: Pekka Savola To: "Nick 'Sharkey' Moore" cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... In-Reply-To: <20021015125759.B23137@dwerryhouse.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Oct 2002, Nick 'Sharkey' Moore wrote: A few comments on some portions of the draft. On the general approach, first: 1) the draft needs to spell out much more clearly how the modifications to RFC2461/RFC2462 (and whether they have been done) affect on the behaviour on the links where there have or haven't been upgraded nodes. 2) I'm not sure if this is the right approach. Something better suited could be found, I believe, in adding functionality to first-hop routers' ND cache behaviour; a router could answer directly which could be interpreted like "don't use that address, I just recently saw it used here by another node.. but if you're really sure you want it, perform DAD as specified in RFC2461/2". Two particular nits: 1) [DUPONT] has had a revision. 2) Optimistic DAD is a useful optimization because DAD is far more likely to succeed than fail, by a factor of at least 10,000,000,000 to one[SOTO]. This makes it worth a little disruption in the failure case to provide faster handovers in the successful case, as long as the disruption is recoverable. ==> this is totally, and completely wrong. [SOTO] only provide analysis in *some* cases, in particular autoconfigured vs privacy addresses. For manually assigned addresses, I believe the ratio is closer to 1:10 or 1:100 (unmeasurable, of course). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 03:12:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HACu29005778; Thu, 17 Oct 2002 03:12:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HACutK005777; Thu, 17 Oct 2002 03:12:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HACq29005761 for ; Thu, 17 Oct 2002 03:12:52 -0700 (PDT) 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 g9HABYPG016580 for ; Thu, 17 Oct 2002 03:11:34 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04259 for ; Thu, 17 Oct 2002 04:11:28 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9HABIu23176; Thu, 17 Oct 2002 13:11:18 +0300 Date: Thu, 17 Oct 2002 13:11:18 +0300 (EEST) From: Pekka Savola To: Derek Fawcus cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <20021017014040.B8106@edi-view1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Oct 2002, Derek Fawcus wrote: > I think this draft is a poor idea, and that if people want an > autoconfig mechanism, then something along the lines of > draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible. > > Mind one would still have to configure the router to generate the > above option in a RA, but then something would always have to be > configured somewhere. Yes, I believe the above draft is a good, simple starting point. There are still some unnecessary assumptions and extra text, I'll send specific comments later. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 03:43:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HAh029005914; Thu, 17 Oct 2002 03:43:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HAh0OE005913; Thu, 17 Oct 2002 03:43:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HAgu29005906 for ; Thu, 17 Oct 2002 03:42:57 -0700 (PDT) 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 g9HAh3PG019993 for ; Thu, 17 Oct 2002 03:43:03 -0700 (PDT) Received: from mail017.syd.optusnet.com.au (mail017.syd.optusnet.com.au [210.49.20.175]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02956 for ; Thu, 17 Oct 2002 03:42:57 -0700 (PDT) Received: from co3016429a (c17345.lowrp1.vic.optusnet.com.au [210.49.213.205]) by mail017.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g9HAgjC07287; Thu, 17 Oct 2002 20:42:46 +1000 Message-ID: <002601c275ca$768868d0$cdd531d2@co3016429a> From: "Richard Nelson" To: "James Kempf" , "Bound, Jim" , "Brett Pentland" , "Thomas Narten" , "Greg Daley" Cc: References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE953F@tayexc13.americas.cpqcorp.net> <008a01c2752a$68255af0$146015ac@T23KEMPF> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Thu, 17 Oct 2002 20:46:33 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have implemented and tested it. Greg Daley was modifying radvd for hmip so he added this as well. We have combined it with link layer signalling to trigger router solicitations (Nick and Bretts work). The combination of HMIP, triggered RS, fast RA and HMIP is very effective in an 802.11 environment L3 handover is much shorter than L2. In the absence of fast handover support we think this is a good solution. We will be publishing test results soon although we could put some preliminary ones up on a website if anybody wanted to see them. Richard. ----- Original Message ----- From: "James Kempf" To: "Bound, Jim" ; "Brett Pentland" ; "Thomas Narten" Cc: Sent: Thursday, October 17, 2002 1:40 AM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > Jim, > > We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses > the 802.11 reassociate for a link up trigger to cause the RS. There is a > substantial decrease in packet loss, on the order of the router beacon. This > requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We > have not implemented the optimization described in the draft yet. > > jak > > > ----- Original Message ----- > From: "Bound, Jim" > To: "James Kempf" ; "Brett Pentland" > ; "Thomas Narten" > Cc: > Sent: Wednesday, October 16, 2002 8:19 AM > Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > > James, > > > > Have you actually tested this with implementation? Or is this > > theoretical debate? > > > > Thanks > > /jim > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, October 15, 2002 5:40 PM > > To: Brett Pentland; Thomas Narten > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > > > > Thomas, > > > > > Seems to me then that this document is a bit narrowly scoped and may > > > even miss the point. Don't we need to look at the overall problem and > > > then see what can be done to address the overall problem adequately? > > > In general, I don't know that its all that useful to focus on a narrow > > > > > part of a bigger problem unless the bigger problem is sufficiently > > > understood that the point solution is understood to be an important > > > and useful component of it. How do we know that this change will make > > > > > any significant difference in practice given the general problem? > > > > > > > You are right that this document is fairly narrowly scoped. To solve the > > full problem, it requires other parts of the ND process, specifically > > DAD, to be accelerated as well. Additionally, as was brought up on the > > list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As > > was also brought up on the list, this can lead to congestion when mobile > > nodes move in concert, or when an access point crashes. > > > > The FMIPv6 work is certainly a more comprehensive solution, however, the > > currently understanding of how FMIPv6 would work together with 802.11 is > > not encouraging. There is, of course, an argument about how much the > > IETF should modify its specifications to be implementable on a specific > > link layer. However, for 802.11 to work well with FMIP, there would > > either need to be a major change in the current firmware implementations > > for anticipated handover, or an additional protocol would be needed > > between the AP and the AR for conveying the reassociation link up > > trigger to the AR, or some special kind of security association would be > > required between the old AR and the MN in order to do unsolicited FBU > > signaling from the AR to the MN. The IETF can do some work on the last > > two of these but the first one is entirely controlled by the IEEE and, > > worse, by card manufacturers who may or may not implement given that > > IEEE has no standard. > > > > So the deployment alternative with ND as defined in RFC 2461 and the > > base FMIPv6 document if one wants faster 802.11 handovers is to set > > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. > > Near term, this is likely to be what people do. With this deployment, > > not only could the above two problems with congestion occur, but the > > router is now subject to DoS attacks. The advantage of the proposal in > > draft-khalil-ipng-fastra-00.txt is that the authors believe it would > > reduce the potential for DoS attacks. > > > > Whether or not this is enough of an improvement over the RS reply > > algorithm as defined by RFC 2461 to standardize, is something for WG and > > the IESG to decide. > > > > jak > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 17 04:36:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HBaZ29006075; Thu, 17 Oct 2002 04:36:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HBaYCL006074; Thu, 17 Oct 2002 04:36:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HBaV29006067 for ; Thu, 17 Oct 2002 04:36:31 -0700 (PDT) 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 g9HBabMq026962 for ; Thu, 17 Oct 2002 04:36:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA27705 for ; Thu, 17 Oct 2002 05:36:31 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06547; Thu, 17 Oct 2002 07:34:17 -0400 (EDT) Message-Id: <200210171134.HAA06547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-08.txt Date: Thu, 17 Oct 2002 07:34:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-08.txt Pages : 83 Date : 2002-10-16 This document provides sockets APIs to support 'advanced' IPv6 applications, as a supplement to a separate specification, RFC 2553. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path MTU information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the 'r' commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2292bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.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: <2002-10-16152919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-16152919.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 Oct 17 05:57:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HCv729006396; Thu, 17 Oct 2002 05:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HCv78P006395; Thu, 17 Oct 2002 05:57:07 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HCv429006388 for ; Thu, 17 Oct 2002 05:57:04 -0700 (PDT) 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 g9HCvBMq006583 for ; Thu, 17 Oct 2002 05:57:11 -0700 (PDT) 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 FAA04063 for ; Thu, 17 Oct 2002 05:57:05 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6BA996A90A; Thu, 17 Oct 2002 15:57:03 +0300 (EEST) Message-ID: <3DAEB518.1060501@kolumbus.fi> Date: Thu, 17 Oct 2002 16:03:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: juha.wiljakka@nokia.com Cc: ipng@sunroof.eng.sun.com, john.loughney@nokia.com Subject: Re: IPv6 node requirements - some comments References: <245DBCAEEC4F074CB77B3F984FF9834FDC352C@esebe005.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk juha.wiljakka@nokia.com wrote: > Hi all, > > it has been quite silent around "IPv6 node requirements" lately. > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-01.txt > > Here are some comments on it to hopefully activate the discussion again: > > - 1.2: There has been discussion on using the conformance groups. Somehow I would feel much more comfortable with the conventional MUST / SHOULD / MAY keywords. Me too. What is essential also, however, is that we retain the conditional concept. I would propose the following terminology: unconditionally mandatory => MUST support ... conditionally mandatory => MUST support ..., when ... or SHOULD support ..., when ... (depending on case) unconditionally optional => MAY support ... > - 2.: Abbreviations list should be made more complete, i.e. adding PPP, ATM, FDDI, NBMA, etc. abbreviations mentioned in the document Yes. > - 3.1.8: IMHO, RFC2529 is a transition mechanism and does not very well fit here... > > - 4.1.1: As RFC2460 is one of the most relevant IPv6 RFCs, I'm just wondering, whether so long descriptive text is actually needed in this document? Would just saying that RFC2460 is mandatory / MUST do the job? I agree that the text should be crisper, but I don't agree that we should remove actual information. For instance, routing is optional whereas acting as an endpoint is mandatory. > - 4.4 and 4._1_.1 Why making this subchapter, i.e. could ICMPv6 RFC just be mentioned in 4.4? > > - 4.5.5 and 5.3.1: Should we combine these and have DHCPv6 mentioned only in 4.5.5? > > - 5. Why are DNS and Transport Layers in the same chapter? => make separate chapters? These are probably due to a general decision on the structure of the document. John? > - 5.2: DNS discovery is an important and missing thing here, I propose mentioning at least this mechanism here > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-06.txt > > - 6.: What should we do with the transition things in this document? Is this something we should totally leave for v6ops wg? As we all know, 4 design teams (unmanaged, enterprise, ISP and cellular) are working at the moment. > > - 7.: I think we should wait until the MIPv6 RFC has been completed to finalize this section. IMHO, at least things that are mandatory for all IPv6 nodes should be mentioned / actually specified here. Route Optimization requirements for all Correspondent Nodes may also be mentioned here. But what comes to Mobile Node or Home Agent functionality, maybe those do not belong to this "minimum IPv6 node requirements" document. I don't recall the name of this document was minimal ipv6 node requirements. In fact, we have listed plenty of optional things. So, I think route optimization is a SHOULD, mobile node is a MAY, and the routers... hmmm... I'm not sure if we were treating router functionality? If we are, then its a MAY. 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 Oct 17 06:21:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HDL529006494; Thu, 17 Oct 2002 06:21:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HDL5t3006493; Thu, 17 Oct 2002 06:21:05 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HDKx29006486 for ; Thu, 17 Oct 2002 06:20:59 -0700 (PDT) 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 g9HDL6Mq011262 for ; Thu, 17 Oct 2002 06:21:06 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20985 for ; Thu, 17 Oct 2002 07:21:00 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9HDKfKV029415; Thu, 17 Oct 2002 15:20:41 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Oct 2002 15:20:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B81@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , "Nick 'Sharkey' Moore" Cc: ipng@sunroof.eng.sun.com Subject: RE: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 15:20:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Optimistic DAD is a useful optimization because DAD is far more > likely to succeed than fail, by a factor of at least > 10,000,000,000 > to one[SOTO]. This makes it worth a little disruption > in the failure > case to provide faster handovers in the successful case, > as long as > the disruption is recoverable. > > ==> this is totally, and completely wrong. [SOTO] only > provide analysis > in *some* cases, in particular autoconfigured vs privacy > addresses. For > manually assigned addresses, I believe the ratio is closer > to 1:10 or > 1:100 (unmeasurable, of course). => I think that manually configuring a CoA is not something we should do or talk about in standards. So it is probably not important to include it in any useful (useable) statistics on the probability of address duplication. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 06:45:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HDjQ29006676; Thu, 17 Oct 2002 06:45:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HDjQrs006675; Thu, 17 Oct 2002 06:45:26 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HDjN29006668 for ; Thu, 17 Oct 2002 06:45:23 -0700 (PDT) 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 g9HDjTMq018126 for ; Thu, 17 Oct 2002 06:45:29 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08101 for ; Thu, 17 Oct 2002 07:45:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9HDj9L25053; Thu, 17 Oct 2002 16:45:09 +0300 Date: Thu, 17 Oct 2002 16:45:09 +0300 (EEST) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: "Nick 'Sharkey' Moore" , Subject: RE: Optimistic DAD draft ... In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0B81@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Oct 2002, Hesham Soliman (EAB) wrote: > > Optimistic DAD is a useful optimization because DAD is far more > > likely to succeed than fail, by a factor of at least > > 10,000,000,000 > > to one[SOTO]. This makes it worth a little disruption > > in the failure > > case to provide faster handovers in the successful case, > > as long as > > the disruption is recoverable. > > > > ==> this is totally, and completely wrong. [SOTO] only > > provide analysis > > in *some* cases, in particular autoconfigured vs privacy > > addresses. For > > manually assigned addresses, I believe the ratio is closer > > to 1:10 or > > 1:100 (unmeasurable, of course). > > => I think that manually configuring a CoA is not > something we should do or talk about in standards. > So it is probably not important to include it in > any useful (useable) statistics on the probability > of address duplication. I agree, but the analysis was done on the specific case, not the generic case. The wording is wrong. The optimistic DAD extensions could be used outside of the MIPv6 context too! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 07:11:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEBg29007219; Thu, 17 Oct 2002 07:11:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HEBgEQ007218; Thu, 17 Oct 2002 07:11:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEBd29007211 for ; Thu, 17 Oct 2002 07:11:39 -0700 (PDT) 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 g9HEBjMq022753 for ; Thu, 17 Oct 2002 07:11:45 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25951 for ; Thu, 17 Oct 2002 08:11:39 -0600 (MDT) From: juha.wiljakka@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 g9HEBeH28878 for ; Thu, 17 Oct 2002 17:11:41 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 17 Oct 2002 17:11:38 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 17:11:37 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 17 Oct 2002 17:11:36 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3536@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJ1dqqKOBDmzmMmR4KqpH8ftR/Y+gABfCaAABnBe9A= To: X-OriginalArrivalTime: 17 Oct 2002 14:11:37.0433 (UTC) FILETIME=[1B37C490:01C275E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HEBd29007212 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, as an individual I want to give my full support for this draft. The main point is that to make IPv6 deployed *now*, we really need a mechanism for DNS discovery. I am very much afraid that if we now wait for the perfect solution, it will come all too late. However, it is fine for me that better / more robust mechanisms are being developed, but let's make this (and IPv6) happen now. Best Regards, -Juha W.- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 07:40:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEeZ29007391; Thu, 17 Oct 2002 07:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HEeZjK007390; Thu, 17 Oct 2002 07:40:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEeV29007380 for ; Thu, 17 Oct 2002 07:40:31 -0700 (PDT) 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 g9HEecPG022462 for ; Thu, 17 Oct 2002 07:40:38 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09526 for ; Thu, 17 Oct 2002 07:40:32 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9HEeUKV022550; Thu, 17 Oct 2002 16:40:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Oct 2002 16:40:31 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B84@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Date: Thu, 17 Oct 2002 16:40:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I must chime in to say I dislike this approach a bit, but > it could be > salvageable. (Though, I must admit I like an option in RA's more..) > > Most of all, I dislike using *3* well known site local > addresses. One > should suffice just fine. Remember that this mechanism, at > least in my > eyes, is intended for *bootstrapping* only. => Hmm. I wonder if 1 address is enough. What if _that_ DNS crashed? Of course we can reuse that same address on other DNSs... oops we can't use anycast. I didn't really get the impression about this mechanism is only for bootstrapping, although the example you mention can certainly be done. Maybe the authors or someone else can clarify. After there is > something that > works, one could use some other mechanism (e.g. a DNS lookup :-) to > discover *real* DNS server addresses and ignore the site > local. It seems > to me that _3_ addresses just triples delays (5-10 seconds > each, per DNS > lookup?) if none of those have been configured in the site. => I think you're arguing for "how a host knows if it should use this mechanism" or "what is the deafult?". If this question is handled, the number of addresses is only relevant for redundancy. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 07:41:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEfj29007408; Thu, 17 Oct 2002 07:41:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HEfjQr007407; Thu, 17 Oct 2002 07:41:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEfe29007400 for ; Thu, 17 Oct 2002 07:41:40 -0700 (PDT) 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 g9HEflPG022626 for ; Thu, 17 Oct 2002 07:41:47 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05593 for ; Thu, 17 Oct 2002 08:41:40 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:e80f:f93c:85be:9214]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9HEfYt77929; Thu, 17 Oct 2002 23:41:34 +0900 (JST) Date: Thu, 17 Oct 2002 23:42:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@us.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-08.txt In-Reply-To: <200210171134.HAA06547@ietf.org> References: <200210171134.HAA06547@ietf.org> <200208062005.g76K5Yp03177@rotala.raleigh.ibm.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: 289 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 17 Oct 2002 07:34:17 -0400, >>>>> Internet-Drafts@ietf.org said: > Title : Advanced Sockets API for IPv6 > Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei > Filename : draft-ietf-ipngwg-rfc2292bis-08.txt > Pages : 83 > Date : 2002-10-16 I believe I addressed all the points you provided (as an AD review) and related comments from Jack (McCann) in this revision, and so the draft should be ready for an IESG review. If you also think this is okay, please pass it to the IESG. Just FYI, below I've attached the change list, and briefly explained that I addressed your comments citing your original message. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Here is the change list: - Changed the type of some function arguments and return values from size_t to int or socklen_t to be aligned with the latest POSIX. Revised code examples accordingly. - Used PF_xxx instead of AF_xxx. - Replaced MUST with must. - Made the URL of assigned numbers less specific so that it would be more robust for future changes. - Changed the reference to the basic API from RFC2553 to the latest Internet Draft. - Added a sentence to mention that this document is intended to replace RFC2292. - Revised abstract to be more clear and concise, particularly concentrating on differences from RFC2292. - Removed traceroute as a usage of returning the received hop limit. - Moved new definitions about CMSG_xxx from appendices to the document body. - Added a reference to the latest POSIX standard. - Clarified that inet6_opt_init() may return a constant, but this document left it as implementation dependent. - Changed the argument name "prevlen" in inet6_opt_xxx() function prototypes to "offset", which better describes the intended usage. - Revised the text about the minimum MTU for multicast to make it clear that the default behavior came from operation practices. - Many other style and wording improvements. (end of the list) Here are brief responses to your comments: >>>>> On Tue, 06 Aug 2002 16:05:34 -0400, >>>>> Thomas Narten said: > Abstract: > take out the references; saying "rfc 2553" without making it a > reference is OK. See the RFC editors guidelines on abstracts for more > details (draft-rfc-editor-rfc2223bis-02.txt). > Note: the abstract itself could really be rewritten to be more > clear/concise. => I've totally rewritten abstract. > Early in the introduction, the document should say it is > updating/replacing the RFC 2292. => done. > General: it would be good to have a proper reference to the posix > standards in the references section. I.e.: => done. >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary >> data fields are part of the Posix.1g standard and should therefore be >> adopted by most vendors. > Also, how does this align with the Austin group work and the revised > basic API? Are the documents in sync with each other? I say this > because the Basic API is apparently in alignment with the Austin Group > work. It would probably be useful to have some text saying how this > document relates to that standard. > Also, take a look at the most recent changes to the basic API. Do any > spill over into this document? One change to the basic API that seems > relevant to this one: => At least I've tried to make the document aligned with the standard as much as possible, with great help from Jack. >> . More alignments with [3]: >> - [3] does not contain protocol family definitions (PF_xxx). >> Replaced PF_INET6 with AF_INET6, or removed as appropriate. > This document still refernces PF_INET, etc. => fixed. > I note that there are some new ICMP types that have been assigned that > this document doesn't seem to reference (e.g., those greater than > 138). Should they be added? => We've agreed that we do not need additional definitions. >> are taken from http://www.iana.org/assignments/protocol-numbers. > this URL should be restricted to http://www.iana.org/numbers.html (the > URL in the document is not stable over long periods of time) => fixed. >> All data sent via raw sockets MUST be in network byte order and all > s/MUST/must/? (this document doesn't really use MUST/MAY/SHOULD > language). Either downcase this usage here, or include a definition > (e.g., a reference to the 2119 definitions). => replaced with must (not MUST). >> In order to clear an installed filter the application can issue a >> setsockopt for ICMP6_FILTER with a zero length. When no such filter >> has been installed corresponding getsockopt() will return the kernel >> default filter. > last part doesn't parse quite right. > s/installed corresponding/installed, / ?? => fixed. >> We note that many of the functions and socket options defined in this >> document may have error returns that are not defined in this >> document. Many of these possible error returns will be recognized >> only as implementations proceed. > This might have been true the first time this document was > produced. Is it still true today? => basically yes, as I answered before in this list. I've slightly modified the wording though. >> 4.3BSD Reno sockets API in 1990. The reason is that these ancillary >> data fields are part of the Posix.1g standard and should therefore be >> adopted by most vendors. > why are there appendices? seems like at least some of these are part of > the spec itself. Putting them in the appendices would imply that they > perhaps aren't important. => moved extensions in this document to the body (not appendices). > Re: references to RFC 2553; should they point to the revised ID > instead? (since it is about ready to become an RFC) > note: "int " is used throughout. Is this a short/long int? Does this > need to be clarified, or is the current usage adequate? => as I answered in this list, all the "int" should be okay. >> inet6_opt_set_val() - add one component of the option content to the option >> >> Three functions deal with a returned options header: >> >> inet6_opt_next() - extract the next option from the options header >> inet6_opt_find() - extract an option of a specified type from the header >> inet6_opt_get_val() - retrieve one component of the option content > some of the lines go beyond column 80(?). Rfc editor won't allow > that. Can you reformat to keep lines within acceptable length? (Check > the RFC editor formatting rules for details.) => fixed. >> 5. Extensions to Socket Ancillary Data >> >> This specification uses ancillary data as defined in Posix.1g with >> the following compatible extensions: > should this ID also include text relative to the austin group work? => done (added a proper reference). >> - A new CMSG_SPACE macro is defined. It is used to determine how much >> space need to be allocated for an ancillary data item. See Section > s/need/needs/ => fixed. >> operation. Returning the received hop limit is useful for programs >> such as Traceroute and for IPv6 applications that need to verify that >> the received hop limit is 255 (e.g., that the packet has not been >> forwarded). > how does this help traceroute? Traceroute needs to set, not receive > the ttl. => traceroute as an example was removed. >> To specify the outgoing traffic class value, just specify the control >> information as ancillary data for sendmsg() or using setsockopt(). >> Just like the hop limit value, the interpretation of the integer >> traffic class value is >> >> x < -1: return an error of EINVAL >> x == -1: use kernel default >> 0 <= x <= 255: use x >> x >= 256: return an error of EINVAL > note that the terminology surrounding diffserv/traffic class has > changed (see RFC 3260). Is the current API still OK? there are only 64 > diffserv values now. (I think this is OK, but the authors should recheck). => made it sure that this is okay. >> ENXIO The interface specified by ipi6_ifindex does not exist >> >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for >> IPv6 use. >> > Indention not right. (too far to left) => fixed. >> This document and [RFC-2553] specify various methods that affect the >> selection of the packet's outgoing interface. This subsection >> summarizes the ordering among those in order to ensure determined >> behavior. > s/determined/deterministic/? => fixed (replaced with deterministic). >> every multicast packet on the corresponding socket. The reason for >> the ordering comes from expectation that the source address is >> specified as well and that the pair of the address and the outgoing >> interface should be desired. > s/desired/preferred/? => fixed (replaced with preferred). > Source routing with IPv4 sockets API (the IP_OPTIONS socket option) > s/with/with the/ ? => fixed (replaced with "with the"). >> int inet6_opt_init(void *extbuf, size_t extlen); >> >> This function returns the number of bytes needed for the empty >> extension header i.e. without any options. > I don't understand this sentence. Does this then always return the > same value? And doesn't an "empty" header require 0 bytes? Or is this > actually "length remaining"? > Actully, the "length" field is weird in subsequent usages to. Is it > really a length, or an offset into the options? Calling it length is > confusing. Is it too late to change this? => added more text to clarify this. also, the parameter name "prevlen" was changed to "offset". >> - The new inet6_opt_XXX() functions were made different that the old > s/that/than/ => fixed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 07:44:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEig29007452; Thu, 17 Oct 2002 07:44:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HEif6Y007451; Thu, 17 Oct 2002 07:44:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEib29007444 for ; Thu, 17 Oct 2002 07:44:37 -0700 (PDT) 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 g9HEihPG023094 for ; Thu, 17 Oct 2002 07:44:44 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18623 for ; Thu, 17 Oct 2002 08:44:38 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:e80f:f93c:85be:9214]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9HEiWt77968; Thu, 17 Oct 2002 23:44:32 +0900 (JST) Date: Thu, 17 Oct 2002 23:45:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@us.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-08.txt In-Reply-To: References: <200210171134.HAA06547@ietf.org> <200208062005.g76K5Yp03177@rotala.raleigh.ibm.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: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 17 Oct 2002 23:42:20 +0900, >>>>> JINMEI Tatuya said: > Just FYI, below I've attached the change list, and briefly explained > that I addressed your comments citing your original message. Oops, sorry, I forgot one more point: >> Re: references to RFC 2553; should they point to the revised ID >> instead? (since it is about ready to become an RFC) It now referred to the revised ID. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 07:50:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEoO29007553; Thu, 17 Oct 2002 07:50:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HEoORf007552; Thu, 17 Oct 2002 07:50:24 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HEoL29007545 for ; Thu, 17 Oct 2002 07:50:21 -0700 (PDT) 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 g9HEoRMq029270 for ; Thu, 17 Oct 2002 07:50:27 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22998 for ; Thu, 17 Oct 2002 08:50:22 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HEoL0K300936 for ; Thu, 17 Oct 2002 10:50:21 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9HEoINU137442 for ; Thu, 17 Oct 2002 10:50:19 -0400 Importance: Normal Sensitivity: Subject: IPv6 MIB team - new RFC2012 draft To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Thu, 17 Oct 2002 10:50:18 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/17/2002 08:50:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 7/10/2002 Margaret Wasserman appended the following to the one of the MIB mailing lists: >>An issue came up when reviewing our updates to the TCP & UDP >>MIBs that may affect other MIBs. >>Due to the changes in the InetAddressType TC to define different >>types for global and non-global addresses, it is now necessary >>to include InetAddressType variables in places where they were >>not previously needed. >>To give an example: >>In our TCP MIB, we have a connection table indexed by >>a local address, a remote address and two ports. In >>previous versions of the MIB, we had one InetAddressType >>index that was stated to apply to both addresses. >>However, with the new definition of InetAddressType, we >>need to provide two different type variables (a local >>address type, and a remote address type), because it is >>possible to have a connection between a global IPv6 >>address and a non-global IPv6 address (for example). We are trying to implement the tcpConnectionTable from the June 2002 version of the new RFC2012 draft but there is no tcpConnectionRemAddressType MIB object defined in this version of the draft. Is this MIB object going to be added to this table? 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 Oct 17 08:47:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFlE29007990; Thu, 17 Oct 2002 08:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HFlDK8007989; Thu, 17 Oct 2002 08:47:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFlA29007982 for ; Thu, 17 Oct 2002 08:47:10 -0700 (PDT) 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 g9HFlHPG006596 for ; Thu, 17 Oct 2002 08:47:17 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17865 for ; Thu, 17 Oct 2002 09:47:10 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HFl80K069154 for ; Thu, 17 Oct 2002 11:47:08 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9HFl6NU095656 for ; Thu, 17 Oct 2002 11:47:06 -0400 Importance: Normal Sensitivity: Subject: Re: IPv6 MIB team - new RFC2012 draft To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Thu, 17 Oct 2002 11:47:06 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/17/2002 09:47:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rajiv, Thanks for the quick feedback on the tcpConnectionRemAddressType MIB object. Will this new MIB object be inserted before the existing tcpConnectionRemAddress MIB object and will the rest of the objects in the table be renumbered? Also, are all 4 drafts being revised for the Nov. 4 date? And are any of the revised drafts available now so we can see what kind of changes have been made since the June/July revisions? 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 Oct 17 08:57:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFvR29008065; Thu, 17 Oct 2002 08:57:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HFvRCF008064; Thu, 17 Oct 2002 08:57:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFvO29008057 for ; Thu, 17 Oct 2002 08:57:24 -0700 (PDT) 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 g9HFvUPG008870 for ; Thu, 17 Oct 2002 08:57:30 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27744 for ; Thu, 17 Oct 2002 08:57:25 -0700 (PDT) Message-ID: <00e701c275f5$9d627d30$706015ac@T23KEMPF> From: "James Kempf" To: "Nick 'Sharkey' Moore" , "Bound, Jim" Cc: "Alper E. YEGIN" , "Pekka Savola" , References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E9@tayexc13.americas.cpqcorp.net> <20021017174457.C3569@dwerryhouse.com.au> Subject: Re: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 08:24:36 -0700 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 Nick, > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current form, it probably > isn't scalable to that level, but sadly I don't have a megapolis > to test it with -- I'm a research engineer not a product engineer :-) > With the latest FMIPv6 draft, HMIP isn't really necessary as a handover optimization technology, though it can contribute if routers supporting FMIPv6 are not an option. However, it is very useful for providing a primitive form of location privacy, because it hides movement within a geographical area. The European Union issues an opinion last spring (Opinion 2/2002: On the use of unique identifiers in telecommunications equipment: the example of IPv6) which discusses location privacy. HMIPv6 would be useful in satisfying that requirement. W.r.t. scalability, simulation is typically the best way to test scalability lacking a megapolis. I think it would be extremely useful to have a simulation of HMIP. There are caveats in using simulation, of course. I don't think simulation is necessary to go to PS, however, it will certainly be necessary for recommending HMIP to operators who are interested in deployment. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 08:57:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFvb29008078; Thu, 17 Oct 2002 08:57:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HFva8c008077; Thu, 17 Oct 2002 08:57:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HFvX29008070 for ; Thu, 17 Oct 2002 08:57:33 -0700 (PDT) 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 g9HFvdPG008911 for ; Thu, 17 Oct 2002 08:57:39 -0700 (PDT) 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 JAA11983 for ; Thu, 17 Oct 2002 09:57:33 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA19290; Thu, 17 Oct 2002 08:56:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20021017115702.03ab28e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 11:58:01 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Cc: "'Pekka Savola'" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0B84@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I didn't really get the impression about this mechanism >is only for bootstrapping, although the example you >mention can certainly be done. Maybe the authors or >someone else can clarify. As specified, this is not a bootstrapping mechanism. A host is expected to continue to use these the three default addresses to reach DNS servers unless/until it is configured to do otherwise. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 09:17:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HGHu29008271; Thu, 17 Oct 2002 09:17:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HGHujd008270; Thu, 17 Oct 2002 09:17:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HGHr29008263 for ; Thu, 17 Oct 2002 09:17:53 -0700 (PDT) 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 g9HGHxPG013885 for ; Thu, 17 Oct 2002 09:17:59 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06527 for ; Thu, 17 Oct 2002 10:17:53 -0600 (MDT) Message-ID: <00ed01c275f8$85765860$706015ac@T23KEMPF> From: "James Kempf" To: , "Bob Hinden" References: <4.3.2.7.2.20021016115156.028ed2c8@mailhost.iprg.nokia.com> Subject: Re: Comments on IPv6 Flow Label Last Call Date: Thu, 17 Oct 2002 09:16:14 -0700 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 I had a look at this draft. Specific comments below. > The IPv6 w.g. chairs believe there are some important open issues that they > would like to see the working group discuss as part of the working group > last call on the "IPv6 Flow Label Specification" > . > > The current draft allows flow labels to be used in ways that go beyond the > consensus that was reached when the working group agreed to make this > document a working group document. This consensus was that the flow label > would be set by a source node to label a set of packets (with same source > and destination addresses) that the source wanted to be treated as a > flow. The flow label in this definition did not have any defined > structure. The main application for this was to make it easier for other > nodes to recognize flows without having to search to one or more headers to > find the transport port numbers. I think the draft in its current form is a response to the discussion that came up around flow labels. The current draft contains a few MUSTs, specifically: - The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). (IMHO *the* most important requirement). - IPv6 nodes MUST NOT assume mathematical or other non-mathematical properties of the Flow Label assigned by source nodes. - If an IPv6 node is not provided flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet. - A source node MUST keep track of the Flow Label values it is currently using or has recently used. - When a new flow is instatiated, a unique Flow Label MUST be selected for it (note: I presume this is if the Flow Labels are being used, that is, I don't think this is meant to require *all* IPv6 nodes to use flow labels). - An IPv6 source node MUST provide a facility for selecting and assigning unique Flow Label values, and for storing the Flow Label. - The facility MUST be used whenever a lable needs to be assigned for a new flow. - A flow state establishment method MUST provide the means for flow state cleanup from the IPv6 nodes providing the flow-specific treatment. I think these cover the WG's original concensus on what should be in the draft. The rest of the draft consists of specific requirements on other protocols that are involved in managing flow label usage. As a whole, I find the requirements quite sensible and I believe they will be very useful for guiding development of flow label usage in other working groups. It would be possible to separate out the specification of the flow label per se by taking the above list of MUSTs and putting them in a separate document, but the document would then be quite short (maybe only a page) and the context would missing. I do think, however, that other working groups might find reference to this document easier if the requirements on flow label usage were better organized and listed as specifically numbered items rather than be embedded in text. >The current draft has a number of > features that go beyond this model and permit many other modes. Examples > include: > > - Allowing for other standard specifications to define properties and/or > structure of the flow label field. I actually don't see this. The MUST NOT requirement cited above specifically prohibits assuming any structure to the flow label, for example. > - A strong focus on the assignment of flow label via signaling protocols. The focus is on requirements for signalling protocols, and I think that is valuable. I've been recently thinking about how to use flow labels, and one question that comes up is how to get agreement between two end nodes about what the flow labels should be. This is an important part of the architecture, and the document does a good job in outlining requirements for it. > - Allowing a specific flow label value to be assigned via a signaling > protocol to identify flows with different source and destination > addresses. > This is a concern. I agree that keeping a simple flow label usage might be better for now, until we have more experience. However, I can also see an argument that it might simplify signaling in certain cases, for example, multi-user voice sessions such as a teleconference. > The draft may be trying to accommodate uses of the flow label that were not > agreed to by the working group. > > There are a number of other areas in the draft that need additional > discussion and/or clarification. These include: > > - No default time out for the life time for specific flow label values. > - No requirement that signaling mechanisms must include a lifetime > when providing flow label setup information. I believe the issue here is flow label state, and not flow labels per se. I agree that the document should state that flow label state should be soft state, and that there should be a requirement that flow label state have a specific lifetime. However, as the document is trying to set up requirements, I believe specifying a default lifetime for all applications would be inappropriate. I think it is enough to require that signaling protocols and applications specify a default. The default may differ depending on the application. > - No default mechanisms if flow label values requested via a signaling > mechanisms conflict with existing flow label values. > - Security considerations need to discuss the impact of labeling flows > of encrypted traffic. > It is not immediately clear to me whether additional requirements in this area are needed, but it would not hurt to spend some time considering these. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 09:18:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HGIr29008288; Thu, 17 Oct 2002 09:18:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HGIrK5008287; Thu, 17 Oct 2002 09:18:53 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HGIo29008280 for ; Thu, 17 Oct 2002 09:18:50 -0700 (PDT) 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 g9HGIuMq018477 for ; Thu, 17 Oct 2002 09:18:56 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17194 for ; Thu, 17 Oct 2002 09:18:51 -0700 (PDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 18:18:50 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 17 Oct 2002 18:18:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJxpK6Rbdx3ak3FRPmwiOjoKgmxRAEK/QTg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Rob Austein" , , "Margaret Wasserman" , "Pekka Savola" , X-OriginalArrivalTime: 17 Oct 2002 16:18:50.0625 (UTC) FILETIME=[E0F46F10:01C275F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HGIo29008281 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, few comments below > -----Original Messages ----- > From : Rob Austein [mailto:sra+ipng@hactrn.net] > My main objection was and remains that this mechanism, if used, moves > state away from the endpoints and into the network in a way that > cripples the resolver's ability to keep track of which of the name > servers it is using are performing properly, since the binding between > any particular well-known-address and the name server behind it might > change at any time and since there is no mechanism by which the > resolver can find out that such a change has taken place. > [Luc] I agree with that point that's why I'd prefer that hosts know not-shared unicast adresses of the recursive server (thanks to Rob for definition reminders) those hosts use. > From : Pekka Savola [mailto:pekkas@netcore.fi] > I must chime in to say I dislike this approach a bit, but it could be > salvageable. (Though, I must admit I like an option in RA's more..) > > Most of all, I dislike using *3* well known site local addresses. One > should suffice just fine. Remember that this mechanism, at > least in my > eyes, is intended for *bootstrapping* only. After there is > something that > works, one could use some other mechanism (e.g. a DNS lookup :-) to > discover *real* DNS server addresses and ignore the site > local. It seems > to me that _3_ addresses just triples delays (5-10 seconds > each, per DNS > lookup?) if none of those have been configured in the site. > [Luc] That kind of solution seems interesting. Well-known site-local addresses could help to discover other adresses of recursive servers. But I do think that a lot of work is still needed in that case : - which address to advertise if recursive servers defend several adresses? - how to discover and then choose Domain Names of recursive servers? > In addition, I greatly dislike section 5.2, that is DNS > forwarding between > sites. If we have to implement site-border router behaviour, > let's *NOT* > require it in every cheapo 50$ DSL router. [Luc] That is one of the most awkward point. That draft suppose that any equipement used as a router at site borders must have a DNS relay function (for example: DSL routers, Mobile Phones if Internet Access is shared.) Finally I had found no answer if such a DNS relay breaks DNSSec solutions, I may be another issue. > -----Message d'origine----- > De : Margaret Wasserman [mailto:mrw@windriver.com] > The document states: > > "Thus, it is recommended to implement also other mechanisms for > overriding this default, for example: manual configuration, L2 > mechanisms and/or DHCPv6." > > I think that it should be required (a MUST) that nodes that > implement this specification provide a method to override the > default values manually. [Luc] If other mechanisms are not required that will impose to deploy such solutions (= to integrated those 3 site-local addresses in a lot of DNS and routing system even if other solutions are available) inside our networks to allow the use of devices that only support the use of those 3 well-known site-local addresses. I definitively prefer to mention: "Thus, other mechanisms MUST be implemented for overriding this default, for example: manual configuration, L2 mechanisms and/or DHCPv6..." > > The document should also specify whether the default DNS addresses > will or won't be considered part of the DNS server list when DNS > server addresses are configured via other means. For example, if > a host receives a single DNS server address via DHCP, will it > fall-back to using these well-known addresses if the DNS server > at the DCHP-configured address fails to respond? [Luc] I agree, this must be clarified. > From : juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > as an individual I want to give my full support for this draft. > > The main point is that to make IPv6 deployed *now*, we really > need a mechanism for DNS discovery. I am very much afraid > that if we now wait for the perfect solution, it will come > all too late. > > However, it is fine for me that better / more robust > mechanisms are being developed, but let's make this (and > IPv6) happen now. > [Luc] I do beleive that we must be sure that any solution would not impose strong impact on future solutions. To my mind, some issues are still not resolved. But I do share your point that we do need a mechanism ;+) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 10:03:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HH3v29008489; Thu, 17 Oct 2002 10:03:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HH3ug2008488; Thu, 17 Oct 2002 10:03:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HH3r29008481 for ; Thu, 17 Oct 2002 10:03:53 -0700 (PDT) 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 g9HH3xPG026941 for ; Thu, 17 Oct 2002 10:03:59 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01566 for ; Thu, 17 Oct 2002 11:03:53 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9HH3nKV018622; Thu, 17 Oct 2002 19:03:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Oct 2002 19:03:49 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B86@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'BELOEIL Luc FTRD/DMI/CAE'" , Rob Austein , ipng@sunroof.eng.sun.com, Margaret Wasserman , Pekka Savola , juha.wiljakka@nokia.com Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Date: Thu, 17 Oct 2002 19:03:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Rob, One question From : Rob Austein [mailto:sra+ipng@hactrn.net] > > My main objection was and remains that this mechanism, if > used, moves > > state away from the endpoints and into the network in a way that > > cripples the resolver's ability to keep track of which of the name > > servers it is using are performing properly, since the > binding between > > any particular well-known-address and the name server > behind it might > > change at any time and since there is no mechanism by which the > > resolver can find out that such a change has taken place. > > => Are you assuming that more than one server will be configured with the same well-known site-local address? Because I don't think this is necessary, now that we have 3 different addresses. The binding betweem the well-known address and the name server need not change. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 11:12:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HICD29008733; Thu, 17 Oct 2002 11:12:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HICDrS008732; Thu, 17 Oct 2002 11:12:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HICA29008725 for ; Thu, 17 Oct 2002 11:12:10 -0700 (PDT) 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 g9HICGMq021997 for ; Thu, 17 Oct 2002 11:12:17 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01079 for ; Thu, 17 Oct 2002 11:12:11 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 11:12:11 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Oct 2002 11:12:10 -0700 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 11:12:09 -0700 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: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt Date: Thu, 17 Oct 2002 11:12:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt Thread-Index: AcJ1ecYtBhGUiObcTXO4FBNZ1G9azAAjkxBQ From: "Richard Draves" To: Cc: X-OriginalArrivalTime: 17 Oct 2002 18:12:09.0954 (UTC) FILETIME=[B5ABB420:01C27608] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HICA29008726 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > agreed. you can't pass around scoped address across > nodes (in general) > as the view of the scope differs between nodes. i have > clearer idea > on link-locals, but i have almost no solutions against > site-locals. > there are security issues associated with it (attacking > other company's > inside machine using routing header w/ site-local > address, and such...). I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is that site-locals are put in the DNS and it specifies a way for a node to filter out the site-locals when they shouldn't be used). It can be extended to the situation of an application on one node sending addresses to an application on another node. The simple idea is to just send all your global & site-local addresses, then the receiving node does the same filtering specified by draft-ietf-ipngwg-site-prefixes-05, and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order to try the 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 Thu Oct 17 11:21:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HILX29008832; Thu, 17 Oct 2002 11:21:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HILXfC008831; Thu, 17 Oct 2002 11:21:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HILT29008821 for ; Thu, 17 Oct 2002 11:21:29 -0700 (PDT) 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 g9HILaPG021472 for ; Thu, 17 Oct 2002 11:21:36 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21525 for ; Thu, 17 Oct 2002 12:21:26 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9HIL8l27295; Thu, 17 Oct 2002 21:21:09 +0300 Date: Thu, 17 Oct 2002 21:21:08 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" In-Reply-To: <5.1.0.14.2.20021017115702.03ab28e0@mail.windriver.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, 17 Oct 2002, Margaret Wasserman wrote: > >I didn't really get the impression about this mechanism > >is only for bootstrapping, although the example you > >mention can certainly be done. Maybe the authors or > >someone else can clarify. > > As specified, this is not a bootstrapping mechanism. A host > is expected to continue to use these the three default > addresses to reach DNS servers unless/until it is configured > to do otherwise. Exactly, but this wouldn't have to be so. Introduction: Except for name resolution, all the other services are usually described using names, not addresses, such as smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping reasons, a node needs to be configured with the IP address (and not the name) of a DNS resolver. doesn't really require 3 DNS addresses. If one of the site-locals doesn't answer you, it's highly unlikely that the next one will (ie: not configured at all). If the second doesn't answer either, it is almost unheard of if the third one does answer. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 12:21:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HJLN29009217; Thu, 17 Oct 2002 12:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HJLMNv009216; Thu, 17 Oct 2002 12:21:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HJLI29009209 for ; Thu, 17 Oct 2002 12:21:19 -0700 (PDT) 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 g9HJLPPG009649 for ; Thu, 17 Oct 2002 12:21:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15490 for ; Thu, 17 Oct 2002 12:21:19 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9HJJx005207; Thu, 17 Oct 2002 15:19:59 -0400 (EDT) Message-Id: <200210171919.g9HJJx005207@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Thu, 17 Oct 2002 11:12:09 PDT.") Date: Thu, 17 Oct 2002 15:19:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is > that site-locals are put in the DNS and it specifies a way for a node to > filter out the site-locals when they shouldn't be used). It can be > extended to the situation of an application on one node sending > addresses to an application on another node. The simple idea is to just > send all your global & site-local addresses, then the receiving node > does the same filtering specified by draft-ietf-ipngwg-site-prefixes-05, > and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order > to try the addresses. I have a lot of problems with that document. - it has a wide impact, because it potentially imposes requirements on all IPv6 apps (not just hosts) and/or encourages hosts to filter DNS results that might be meaningful to apps - one result of this is that each component in a distributed app effectively has a different view of DNS. - like a lot of other proposals, it assumes that DNS TTL is somehow related to the binding between an IP address and the host, or the IP address and the application component. It's not. DNS TTL is related to the binding of a name to a resource record. It says nothing about the lifetime of the binding between an address and a host or application component. - like a lot of other proposals, it assumes that apps get their addresses exclusively from DNS, even if indirectly. this is not the case. - it assumes that all AAAA records returned in an RRset refer to the same host. they don't. they're all bound to the same DNS name, which isn't the same thing. - it assumes that an app should prefer site-local addresses over global addresses. but this breaks for apps that (quite reasonably) use source addresses in referrals to other hosts. - address selection is already broken. by creating yet another address for each host/interface that uses them, site locals make the problem even worse. - it doesn't solve the problem with two-faced DNS - it just moves the problem and makes failures more difficult to diagnose. in both cases the party doing the filtering is not in a position to know whether the addresses will be usable by the party that eventually needs to use them. - it artifically fragments the problem space for apps that use long-running connections into "site-local" apps vs "non-site-local" apps. we really need something that supports reasonably long-running connections for both cases. at the same time we should recognize that no address has ever been permanently bound to either a host or an application. we should just establish reasonable expectations for the lifetime of those bindings. apps that need to keep connections open for longer than that would need to define and implement mechanisms for recovery from address changes. that way we could retain location-independence for apps - i.e. they wouldn't need to care whether they were entirely site-local or not. this is just from a brief scan. we're trying to solve a number of problems by creating a separate name for each distinct situation. I don't think it will work - it's just too hard to keep track of which name to use in which case. this proposal makes a good try but actually just ends up illustrating how difficult the problem really is. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 12:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HJZH29009324; Thu, 17 Oct 2002 12:35:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HJZHUj009323; Thu, 17 Oct 2002 12:35:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HJZE29009316 for ; Thu, 17 Oct 2002 12:35:14 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08903 for ; Thu, 17 Oct 2002 15:35:20 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id g9HJZKqG018206 for ; Thu, 17 Oct 2002 15:35:20 -0400 (EDT) Message-Id: <200210171935.g9HJZKqG018206@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: source address selection question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Oct 2002 15:35:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm slightly confused about the following wording in section 4 of the default address selection draft: If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error. The specified source address may influence the candidate set, by affecting the choice of outgoing interface. Could someone clarify the intention of this paragraph? The only input accepted by the source address mechanism specified in this draft is a destination address and a candidate set. Where does an application or an upper-layer get to "specify" a source address in this mechanism? If the intent of the paragraph is to restrict what addresses applications can use as source addresses when this default mechanism isn't used, then I think it's outside the scope of the document. This document should, in my opinion, only deal with the default case when an application has not specified an explicit source address. -Sebastien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 13:09:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HK9D29009580; Thu, 17 Oct 2002 13:09:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HK9DEx009579; Thu, 17 Oct 2002 13:09:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HK9829009572 for ; Thu, 17 Oct 2002 13:09:10 -0700 (PDT) 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 g9HK9FMq000758 for ; Thu, 17 Oct 2002 13:09:15 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22388 for ; Thu, 17 Oct 2002 14:09:08 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 13:08:42 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Oct 2002 13:08:42 -0700 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); Thu, 17 Oct 2002 13:08:42 -0700 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: source address selection question Date: Thu, 17 Oct 2002 13:08:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: source address selection question Thread-Index: AcJ2FLuBb0MZ9z2VRhWG7POkVurjMQAA5yLw From: "Richard Draves" To: "Sebastien Roy" Cc: X-OriginalArrivalTime: 17 Oct 2002 20:08:42.0144 (UTC) FILETIME=[FD573A00:01C27618] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HK9A29009573 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If an application or upper-layer specifies a source address that is > not in the candidate set for the destination, then the > network layer > MUST treat this as an error. The specified source address may > influence the candidate set, by affecting the choice of outgoing > interface. > > Could someone clarify the intention of this paragraph? The intent is that if the application or upper-layer specifies a source address that is clearlyy illegal, then the network layer reports an error instead of sending a packet with an illegal source address. Here are a couple examples: a) The application specifies a source address of ff02::1. b) The application is sending to fe80::1%2, and specifies a source address of fe80::5. But fe80::5 is not assigned to an interface on link 2. 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 Thu Oct 17 13:27:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HKR429009780; Thu, 17 Oct 2002 13:27:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HKR4DO009779; Thu, 17 Oct 2002 13:27:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HKR029009772 for ; Thu, 17 Oct 2002 13:27:01 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09807; Thu, 17 Oct 2002 16:27:06 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id g9HKR6qG018517; Thu, 17 Oct 2002 16:27:06 -0400 (EDT) Message-Id: <200210172027.g9HKR6qG018517@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Richard Draves" cc: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: source address selection question In-Reply-To: Message from "Richard Draves" of "Thu, 17 Oct 2002 13:08:41 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Oct 2002 16:27:06 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If an application or upper-layer specifies a source address that is > > not in the candidate set for the destination, then the > > network layer > > MUST treat this as an error. The specified source address may > > influence the candidate set, by affecting the choice of outgoing > > interface. > > > > Could someone clarify the intention of this paragraph? > > The intent is that if the application or upper-layer specifies a source > address that is clearlyy illegal, then the network layer reports an > error instead of sending a packet with an illegal source address. Here > are a couple examples: > a) The application specifies a source address of ff02::1. > b) The application is sending to fe80::1%2, and specifies a source > address of fe80::5. But fe80::5 is not assigned to an interface on link > 2. > In spirit, this restriction makes sense. I also think that it's outside of the scope of this document, especially given this statement made in the abstract: The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. And this one in the introduction: The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. I can see how implementations could unintentionally violate this MUST in the draft. One example is an implementation that defines a mechanism by which a particular kind of address (marked by a special flag for example) can be used as a source address only through bind(), but not through the default address selection mechanism. In that case, the address is never in any "candidate set", so by the wording you have in the draft, IP should treat the application's use of the address as a source address as an error. I don't believe that specifying such a restriction in this draft is necessary. -Sebastien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 13:37:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HKbh29009979; Thu, 17 Oct 2002 13:37:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HKbg1n009978; Thu, 17 Oct 2002 13:37:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HKbd29009971 for ; Thu, 17 Oct 2002 13:37:39 -0700 (PDT) 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 g9HKbkMq008735 for ; Thu, 17 Oct 2002 13:37:46 -0700 (PDT) Received: from mercury.lss.emc.com (mercury.lss.emc.com [168.159.40.77]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29754 for ; Thu, 17 Oct 2002 13:37:41 -0700 (PDT) Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2653.19) id <4SSCB53A>; Thu, 17 Oct 2002 16:37:33 -0400 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE1A@srmoon> From: "sasson, shuki" To: ipng@sunroof.eng.sun.com Subject: Link Local Address usage for multi-home host. Date: Thu, 17 Oct 2002 16:34:19 -0400 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 g9HKbe29009972 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Link Local Addresses presents a new concept to the existing IPv4 oriented systems. The concept is that two different entities might have the same IPv6 (Link Local Address). The big problem is that this goes up the stack up to the applications. Example: NFS server, we would like to export it for a node that is on the same link using a Link Local address. Up until now mentioning the IP address was enough since it identified the interface. With IPv6 one may have the situation where two different interfaces may have the same Link Local address. In this case the interface should also be mentioned by the user. Another problem (using the NFS example): We may have a situation that two different entities (each of them residing on a different link) will mount the file system. Once again I think most of the application will not work as expected in this case. My Concern: Presenting this ambiguity to the upper layer will require in some cases redesign of the application. I do not think that the developers of the IPv6 protocol were aiming for this... >From the little I have read Link Local addresses are used as a mean to initially communicate with routers in order to establish statefull Address Configuration (Global or Site Local address..). My Questions: 1. Has someone came across the same problem? What was the solution chosen? 2. Should we redesign all the upper layer application to properly support this? 3. Will restricting the applications/clients to communicate only with global addresses makes sense? 4. Will the new socket interface include an interface index to properly resolve this ambiguity? Thanks for your answers, 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 Oct 17 15:09:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HM9029011302; Thu, 17 Oct 2002 15:09:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HM90fO011301; Thu, 17 Oct 2002 15:09:00 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HM8v29011294 for ; Thu, 17 Oct 2002 15:08:57 -0700 (PDT) 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 g9HM93Mq005783 for ; Thu, 17 Oct 2002 15:09:03 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20115 for ; Thu, 17 Oct 2002 15:08:58 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ADBE85B67; Thu, 17 Oct 2002 18:08:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Oct 2002 18:08:57 -0400 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: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 18:08:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE957B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ1sR47uFRy5WZVQ/iwbZylFXoG/QAdqw7A From: "Bound, Jim" To: "Nick 'Sharkey' Moore" Cc: "Alper E. YEGIN" , , "Pekka Savola" , X-OriginalArrivalTime: 17 Oct 2002 22:08:57.0349 (UTC) FILETIME=[C9F02350:01C27629] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HM8v29011295 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick, Doing review of the draft now. It is good. No opinion yet. Don't get me wrong I think we need to solve this I just want to be careful how, because we got that ND stuff a runnin now and test deployed. But many of us have products now in 2nd and 3rd release. But O-DAD appears to be add on so that's cool. Just don't want to burn an interface without just cause so being cool as product engineer :--) On the theoretical discussion. I think the entire layer 3 effort to all agree and standardize (Charlie and others I know clearly are testing) is far far from baked as standard. I do refuse to listen to folks who tell me we are close when I am on the mail list or reading the archive and 5 very very bright people all correct do agree, but none of them will compromise with each other technically. Then I say from 10 years in the IETF working and implementing that this is simply going to take awhile. On the ignore the standard diatribe. I simply believe the people who support my day job are now wanting technology that requires mobile ipv6, ipv6, ipsec/TLS, BGP+, TCP-Multicast-Fixes et al, SCTP, and lots of good technology created here, are simply tired of waiting for us in this community. If they have enough money and opportunity then they can attract the top vendors. I do know of such giants that are ready to discuss lets get vendor x,y,z and contract gurus a,b,c together and make this work. When we are done we can build specifications for standards bodies. That will happen soon. At that point they are not even listening to us here. L2 vs L3. This battle rages. I am positive we require layer 3 handover simply because I believe mobility requires IP to be totally successful and I would argue IPv6 and IPv4 is a dead end street. But per the baked discussion above we are far from agreement on hmipv6, LMM, and PKI (mostly in the market) and without these tid-bits I just don't see L3 happening first. Here is my vision of large $$$$$$ deployment of Mobility: 1. First there is none. Users accept to reconnect first but using IPv6. 2. Second. We get full products with MIPv6 and we still use L2 for handover. Similar to 3G but more 3G+ (I can't say 4G cause I still believe its marketing hype but maybe not I have stopped following it). 3. At some point in the future we finally get to L3 handovers. 4. I believe AAA will be as important as Ipsec and will play a big role in all three cases above to make it work and charge money for it :--) I think #3 best case for true deployment into large enough test beds that it is ready for real deployment (I roam in L.A. from home to airport and stay connected) and will scale across town via the routers, is best case 5 years away. I usually send first draft comments to just the authors and I hope to next week as I do have technical input for you. Regards, /jim -----Original Message----- From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] Sent: Thursday, October 17, 2002 2:45 AM To: Bound, Jim Cc: Alper E. YEGIN; alh-ietf@tndh.net; Pekka Savola; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... On Thu, Oct 17, 2002 at 02:34:59AM -0400, Bound, Jim wrote: > From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] > > > Bound, Jim wrote: > > > > > > None of us working on this are even clear layer 3 handover will > > > ever work? Not sure if that matters does it? Are we talking > > > about the future? > > > We're pretty clear on this: we've tested it. > > Have you tested hmipv6 to the scale that mobility operator working > with ISPs can cover the entire metropolis of L.A.? To clarify: we've been doing some work to identify and isolate the causes of L3 handover delays, and they each seem solvable by one means or another. For example, hmipv6 offers one possible way of eliminating the RTT delay caused by sending BUs. In its current form, it probably isn't scalable to that level, but sadly I don't have a megapolis to test it with -- I'm a research engineer not a product engineer :-) Actually, JinHyeock reminded me that I'd forgotten to mention the Movement Detection Delay ... we've been tackling that with inter-layer signalling to prompt router solicitations. > No one has deployed layer 3 in production environment I am aware of? > Nor would I trust it yet simply because of this mail discussion. Ummm ... I hope it isn't my Optimism which has caused your concerns ... although if you've got technical comments or concerns re: my draft I'd love to hear them. It is, after all, a work in progress. The Optimistic DAD thing comes about because I thought the FH stuff was getting a bit theoretical and I felt that a set of small, easily implemented patches, one per cause of L3 handover delay, would be a good way to move forward in the short term. cheers, -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 15:24:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMOU29011559; Thu, 17 Oct 2002 15:24:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HMOU3Q011558; Thu, 17 Oct 2002 15:24:30 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMOQ29011551 for ; Thu, 17 Oct 2002 15:24:27 -0700 (PDT) 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 g9HMOXMq010329 for ; Thu, 17 Oct 2002 15:24:33 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04716 for ; Thu, 17 Oct 2002 16:24:26 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 295765B5A; Thu, 17 Oct 2002 18:24:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Oct 2002 18:24:25 -0400 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: Optimistic DAD draft ... Date: Thu, 17 Oct 2002 18:24:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9581@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ19eKXGZCSlqApRNuOX+yrfHem7AANek1g From: "Bound, Jim" To: "James Kempf" , "Nick 'Sharkey' Moore" Cc: "Alper E. YEGIN" , "Pekka Savola" , X-OriginalArrivalTime: 17 Oct 2002 22:24:25.0041 (UTC) FILETIME=[F2E2B410:01C2762B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HMOR29011552 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick per hmip I rest my case :---) below. I don't have and opinion not my discipline but I would like to see James, Hesham, you, et al agree :----) How about for the greater good :--) /jim -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, October 17, 2002 10:25 AM To: Nick 'Sharkey' Moore; Bound, Jim Cc: Alper E. YEGIN; Pekka Savola; ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Nick, > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current form, it probably isn't > scalable to that level, but sadly I don't have a megapolis to test it > with -- I'm a research engineer not a product engineer :-) > With the latest FMIPv6 draft, HMIP isn't really necessary as a handover optimization technology, though it can contribute if routers supporting FMIPv6 are not an option. However, it is very useful for providing a primitive form of location privacy, because it hides movement within a geographical area. The European Union issues an opinion last spring (Opinion 2/2002: On the use of unique identifiers in telecommunications equipment: the example of IPv6) which discusses location privacy. HMIPv6 would be useful in satisfying that requirement. W.r.t. scalability, simulation is typically the best way to test scalability lacking a megapolis. I think it would be extremely useful to have a simulation of HMIP. There are caveats in using simulation, of course. I don't think simulation is necessary to go to PS, however, it will certainly be necessary for recommending HMIP to operators who are interested in deployment. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 15:41:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMfo29011847; Thu, 17 Oct 2002 15:41:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HMfod5011846; Thu, 17 Oct 2002 15:41:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMfl29011839 for ; Thu, 17 Oct 2002 15:41:47 -0700 (PDT) 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 g9HMfrPG007803 for ; Thu, 17 Oct 2002 15:41:53 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13303 for ; Thu, 17 Oct 2002 16:41:45 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id A0334146D8; Fri, 18 Oct 2002 08:41:36 +1000 (EST) Date: Fri, 18 Oct 2002 08:41:34 +1000 From: "Nick 'Sharkey' Moore" To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018084132.A7282@dwerryhouse.com.au> References: <20021015125759.B23137@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Oct 17, 2002 at 12:54:34PM +0300 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 17, 2002 at 12:54:34PM +0300, Pekka Savola wrote: > > Optimistic DAD is a useful optimization because DAD is far more > likely to succeed than fail, by a factor of at least 10,000,000,000 > to one[SOTO]. This makes it worth a little disruption in the failure > case to provide faster handovers in the successful case, as long as > the disruption is recoverable. > > ==> this is totally, and completely wrong. [SOTO] only provide analysis > in *some* cases, in particular autoconfigured vs privacy addresses. I see what you mean. I need to make it clear that [SOTO] and I are referring to strongly random addresses ... this is a requirement for my Optimistic DAD draft anyway for exactly this reason. Do you this it is fair to say: DAD is far more likely to succeed than fail FOR RANDOMLY AUTOCONFIGURED ADDRESSES, by a factor of at least 10,000,000,000 to one[SOTO]. Do you think it would be advisable for me to add: Optimistic DAD MUST NOT be used for manually configured addresses ... because as you point out, manually configured addresses are far more likely to fail and being a MobileIP type I'm mainly interested in configuring CoAs anyway. > For manually assigned addresses, I believe the ratio is closer > to 1:10 or 1:100 (unmeasurable, of course). I'd be really interested to know if anyone has any indicative figures on MAC address collision: it is inevitable that somewhere out there there are two adaptors with the same MAC address due to human frailties, but how many? Thanks for your feedback! -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 15:52:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMqm29011940; Thu, 17 Oct 2002 15:52:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HMqmE8011939; Thu, 17 Oct 2002 15:52:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HMqi29011932 for ; Thu, 17 Oct 2002 15:52:44 -0700 (PDT) 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 g9HMqpPG011207 for ; Thu, 17 Oct 2002 15:52:51 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11019 for ; Thu, 17 Oct 2002 15:52:44 -0700 (PDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 00629146D2; Fri, 18 Oct 2002 08:52:33 +1000 (EST) Date: Fri, 18 Oct 2002 08:52:32 +1000 From: "Nick 'Sharkey' Moore" To: James Kempf Cc: "Bound, Jim" , "Alper E. YEGIN" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018085230.B7282@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5E9@tayexc13.americas.cpqcorp.net> <20021017174457.C3569@dwerryhouse.com.au> <00e701c275f5$9d627d30$706015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00e701c275f5$9d627d30$706015ac@T23KEMPF>; from kempf@docomolabs-usa.com on Thu, Oct 17, 2002 at 08:24:36AM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day James, On Thu, Oct 17, 2002 at 08:24:36AM -0700, James Kempf wrote: > > With the latest FMIPv6 draft, HMIP isn't really necessary as a handover > optimization technology, though it can contribute if routers supporting > FMIPv6 are not an option. With all the ... uh ... debate surrounding FMIP drafts, I figured I'd just pick an example I'm more familiar with. Pretty much any mechanism which allows you to keep a stable CoA will work to eliminate the BU RTT delay. I've been thinking about it a bit too, and in many ways the HMIP and three-party-handover mechanisms reduce to the same thing if you think of the MAP as a kind of dummy AR ... > W.r.t. scalability, simulation is typically the best way to test > scalability lacking a megapolis. Yep, we've got some folks here working on an IPv6 simulation suite with OMNeT++, and getting MIP / HMIP / FMIP / etc functionality in there. I'm hoping I can convince them to run me up a million node Optimistic DAD testbed ... -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 16:45:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HNjh29012273; Thu, 17 Oct 2002 16:45:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9HNjh5Z012272; Thu, 17 Oct 2002 16:45:43 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9HNje29012265 for ; Thu, 17 Oct 2002 16:45:40 -0700 (PDT) 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 g9HNjkMq003717 for ; Thu, 17 Oct 2002 16:45:46 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA14843 for ; Thu, 17 Oct 2002 17:45:41 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 16:45:39 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Oct 2002 16:45:39 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 16:45:39 -0700 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="iso-8859-1" Subject: RE: Link Local Address usage for multi-home host. Date: Thu, 17 Oct 2002 16:45:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link Local Address usage for multi-home host. Thread-Index: AcJ2HVmytiiNdpWmTQ669ioh0e2sjgAF9jyw From: "Brian Zill" To: "sasson, shuki" , X-OriginalArrivalTime: 17 Oct 2002 23:45:39.0717 (UTC) FILETIME=[4C6B3B50:01C27637] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9HNje29012266 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, this can be an issue, but it's not really a serious problem. Link-local addresses, like all scoped addresses, are disambiguated via their scope-id (which represents the zone they are valid in). At the application layer, this is part of the sockaddr_in6. So there is no ambiguity. Applications which want to compare two addresses for equivalency simply need to include the scope-id when making the comparision. It's very little work compared to porting an IPv4 app to be a protocol-independent app. To answer your specific questions: 1) Yes, see above. 2) This should be a natural part of making the app protocol-independent. 3) There is no need to do this. In fact, I'm aware of several apps which want to do the opposite (i.e. limit themselves to scoped addresses only, in order to deliberately restrict their reach). 4) As mentioned above, the sockaddr_in6 structure already contains the scope-id field, which serves the purpose you want (note that while the interface index is often the same as the scope-id for link-local addresses, it might not necessarily be so. And for other scopes, the interface index isn't what you want anyway. The scope-id will always disambiguate a scoped address on a given machine). --Brian > -----Original Message----- > From: sasson, shuki [mailto:sasson_shuki@emc.com] > Sent: Thursday, October 17, 2002 13:34 > To: ipng@sunroof.eng.sun.com > Subject: Link Local Address usage for multi-home host. > > > > Hi all, > Link Local Addresses presents a new concept to the existing > IPv4 oriented systems. The concept is that two different > entities might have the same IPv6 (Link Local Address). The > big problem is that this goes up the stack up to the applications. > > Example: > NFS server, we would like to export it for a node that is on > the same link using a Link Local address. Up until now > mentioning the IP address was enough since it identified the > interface. With IPv6 one may have the situation where two > different interfaces may have the same Link Local address. In > this case the interface should also be mentioned by the user. > > Another problem (using the NFS example): > We may have a situation that two different entities (each of > them residing on a different link) will mount the file > system. Once again I think most of the application will not > work as expected in this case. > > > My Concern: > Presenting this ambiguity to the upper layer will require in > some cases redesign of the application. I do not think that > the developers of the IPv6 protocol were aiming for this... > From the little I have read Link Local addresses are used as > a mean to initially communicate with routers in order to > establish statefull Address Configuration (Global or Site > Local address..). > > My Questions: > 1. Has someone came across the same problem? What was the > solution chosen? 2. Should we redesign all the upper layer > application to properly support this? 3. Will restricting the > applications/clients to communicate only with global > addresses makes sense? 4. Will the new socket interface > include an interface index to properly resolve this ambiguity? > > Thanks for your answers, > 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 Thu Oct 17 17:49:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I0nZ29012775; Thu, 17 Oct 2002 17:49:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I0nYIf012774; Thu, 17 Oct 2002 17:49:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I0nU29012767 for ; Thu, 17 Oct 2002 17:49:30 -0700 (PDT) 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 g9I0nbMq019940 for ; Thu, 17 Oct 2002 17:49:37 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14954 for ; Thu, 17 Oct 2002 18:49:31 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9I0nR006942; Thu, 17 Oct 2002 20:49:27 -0400 (EDT) Message-Id: <200210180049.g9I0nR006942@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Thu, 17 Oct 2002 16:45:39 PDT.") Date: Thu, 17 Oct 2002 20:49:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, this can be an issue, but it's not really a serious problem. forcing apps to deal with scopes at all is a serious problem. being able to compare scopes from different addresses only addresses one small aspect of that problem. though making an app 'protocol independent' is one example of having apps deal with scopes since presumably the app may have to deal with a mixture of v4 and v6 addresses, a mixture of v4-only and v6-only and dual-stack hosts, and various kinds of connectivity (no v4, local v4, global v4) X (no v6, local v6 only, global v6) it should not be assumed that it's appropriate to expect every app to be protocol independent. there will be v4-only apps. there will be v6-only apps. there will be apps that can run one or the other but not both. this is a natural consequence of v6 deployment scenarios. app vendors shouldn't expect that limiting themselves to scoped addresses provides anything in the way of security other than delusion. it's not appropriate for the vendor to assume that the site or local environment is secure. bottom line: there is insufficient justification for expecting apps to deal with scoped addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 18:07:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I17R29012892; Thu, 17 Oct 2002 18:07:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I17RVn012891; Thu, 17 Oct 2002 18:07:27 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I17O29012884 for ; Thu, 17 Oct 2002 18:07:24 -0700 (PDT) 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 g9I17VMq023915 for ; Thu, 17 Oct 2002 18:07:31 -0700 (PDT) Received: from mercury.lss.emc.com (mercury.lss.emc.com [168.159.40.77]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04802 for ; Thu, 17 Oct 2002 19:07:25 -0600 (MDT) Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2653.19) id <4SSCB6FT>; Thu, 17 Oct 2002 21:07:17 -0400 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE1F@srmoon> From: "sasson, shuki" To: "'Keith Moore'" , Brian Zill Cc: "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: RE: Link Local Address usage for multi-home host. Date: Thu, 17 Oct 2002 21:04:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith & Brian, thanks for your answers. It seems like there is still some confusion here... Still a few questions: Looking at the documentation I have that Link Local address is FE80::/64 +64 bits of interface ID. There is no place for the zone. Do you mean that the zone will be assigned by the IfIndex of the interface that the message was recieved by? Another question: MAC address is required to be unique (48 bits) a part of the interface ID. Thus the Link Local assigned to it is unique... So why we bother doing DAD? And also If the above is correct we do not have a problem really... Basically, based on the assumtion that Link Local should be unique everywhere. The only possibility of duplicate Link Local Address is miss-configuration by a human. Can we follow what we are doing in IPv4 in case of wrongly configured address? Basically requiring the network manager to deal with that. Thanks, Shuki -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Thursday, October 17, 2002 8:49 PM To: Brian Zill Cc: sasson, shuki; ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. > Yes, this can be an issue, but it's not really a serious problem. forcing apps to deal with scopes at all is a serious problem. being able to compare scopes from different addresses only addresses one small aspect of that problem. though making an app 'protocol independent' is one example of having apps deal with scopes since presumably the app may have to deal with a mixture of v4 and v6 addresses, a mixture of v4-only and v6-only and dual-stack hosts, and various kinds of connectivity (no v4, local v4, global v4) X (no v6, local v6 only, global v6) it should not be assumed that it's appropriate to expect every app to be protocol independent. there will be v4-only apps. there will be v6-only apps. there will be apps that can run one or the other but not both. this is a natural consequence of v6 deployment scenarios. app vendors shouldn't expect that limiting themselves to scoped addresses provides anything in the way of security other than delusion. it's not appropriate for the vendor to assume that the site or local environment is secure. bottom line: there is insufficient justification for expecting apps to deal with scoped addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 18:37:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I1bD29013028; Thu, 17 Oct 2002 18:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I1bCpt013027; Thu, 17 Oct 2002 18:37:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I1b929013020 for ; Thu, 17 Oct 2002 18:37:09 -0700 (PDT) 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 g9I1bFPG020380 for ; Thu, 17 Oct 2002 18:37:16 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16434 for ; Thu, 17 Oct 2002 19:37:09 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 7436F146D2; Fri, 18 Oct 2002 11:37:01 +1000 (EST) Date: Fri, 18 Oct 2002 11:37:01 +1000 From: "Nick 'Sharkey' Moore" To: "Bound, Jim" Cc: James Kempf , "Alper E. YEGIN" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018113700.C8011@dwerryhouse.com.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9581@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9581@tayexc13.americas.cpqcorp.net>; from Jim.Bound@hp.com on Thu, Oct 17, 2002 at 06:24:24PM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 17, 2002 at 06:24:24PM -0400, Bound, Jim wrote: > Nick per hmip I rest my case :---) below. I don't have and opinion not > my discipline but I would like to see James, Hesham, you, et al agree > :----) How about for the greater good :--) Should our opinions collide, we'll reconfigure :-) I guess I'm working from a different angle to most, too: "What is the minimum required for a useful fast, smooth MIPv6" vs. "What is the most perfect system which is still implementable". -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 17 19:07:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I27P29013187; Thu, 17 Oct 2002 19:07:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I27PSC013186; Thu, 17 Oct 2002 19:07:25 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I27M29013179 for ; Thu, 17 Oct 2002 19:07:22 -0700 (PDT) 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 g9I27SMq010149 for ; Thu, 17 Oct 2002 19:07:28 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19470 for ; Thu, 17 Oct 2002 20:07:21 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 8B348146D2; Fri, 18 Oct 2002 12:07:14 +1000 (EST) Date: Fri, 18 Oct 2002 12:07:14 +1000 From: "Nick 'Sharkey' Moore" To: "Hesham Soliman (EAB)" Cc: "Bound, Jim" , "Alper E. YEGIN" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018120713.D8011@dwerryhouse.com.au> References: <4DA6EA82906FD511BE2F00508BCF0538044F0B7C@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0B7C@Esealnt861.al.sw.ericsson.se>; from hesham.soliman@era.ericsson.se on Thu, Oct 17, 2002 at 11:23:25AM +0200 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 17, 2002 at 11:23:25AM +0200, Hesham Soliman (EAB) wrote: > > > For example, hmipv6 offers one possible way of eliminating the RTT > > delay caused by sending BUs. In its current form, it probably > > isn't scalable to that level, > > => Why not? I think it is scalable to that level simply > because you can plug more anchor points as you see > fit. it's as scalable as HAs are in MIPv6. My main concern would be issues to do with the MAP information propagation, and the MAP selection algorithm ... I think there's some common ground between the tactics of HMIP and the FMIP three-party-handover and I suspect the best solution is in that region somewhere ... > => What you're doing (optimistic DAD) can be combined > with Fast Handovers to completely eliminate movement > detection delay. [...] > => My very initial effort (with Karim) with Fast handovers was aimed > at: anticipation + optimistic DAD + HMIPv6. It's tricky getting anticipation signalling out of most 802.11 drivers, but we've had success getting L2 to signal L3 that it has just reassociated, causing L3 to RS. Greg Daley has more information here, I'm sure he'll chip in when he gets back to town ... -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 19:17:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I2HD29013242; Thu, 17 Oct 2002 19:17:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I2HCDP013241; Thu, 17 Oct 2002 19:17:12 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I2H929013234 for ; Thu, 17 Oct 2002 19:17:09 -0700 (PDT) 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 g9I2HGMq011784 for ; Thu, 17 Oct 2002 19:17:16 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16561 for ; Thu, 17 Oct 2002 19:17:11 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 19:17:10 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Oct 2002 19:17:10 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 17 Oct 2002 19:17:10 -0700 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: Link Local Address usage for multi-home host. Date: Thu, 17 Oct 2002 19:17:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link Local Address usage for multi-home host. Thread-Index: AcJ2QrsR1wY1Z+RiRWu7eFK0hjoa6AAAVrUA From: "Brian Zill" To: "sasson, shuki" Cc: X-OriginalArrivalTime: 18 Oct 2002 02:17:10.0517 (UTC) FILETIME=[76F53A50:01C2764C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9I2HA29013235 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Still a few questions: > Looking at the documentation I have that Link Local address > is FE80::/64 +64 bits of interface ID. There is no place for > the zone. Do you mean that the zone will be assigned by the > IfIndex of the interface that the message was recieved by? If I understand your question correctly, then the answer is essentially yes. Packets on the wire do not have a zone field in the header. But an interface is only in a single zone at each scope level (i.e. an interface can only be on one link, or in one site). So a packet received on an interface can be assigned a zone value based on the zone the interface is in (for link-local addresses this is often the interface index, but not necessarily). That zone value is visible to applications via the scope-id field in the sockaddr_in6 structure (assuming an implementation with a socket based API). Going the other way, if you want to send a datagram to a link-local address, the scope-id in the sockaddr_in6 is only used to identify which interface (or set of interfaces) on your machine it is allowed to go out. The zone identifier (scope-id) isn't included in the packet on the wire. > Another question: > MAC address is required to be unique (48 bits) a part of the > interface ID. Thus the Link Local assigned to it is unique... > So why we bother doing DAD? And also If the above is correct > we do not have a problem really... This issue has been long debated in the working group. My impression is that the argument was presented that since (a) there have been cases where the MAC address is not unique (card manufactors have been known to ship NICs which have the same address, for example) and (b) the degree of the problems that result from having duplicate addresses is pretty bad and (c) can be very hard to diagnose, it seemed the safest thing to do was just do DAD anyway. Occasionally various proposals come up to change this in various ways, but we should probably change the subject line before going into that. --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 Oct 17 22:49:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I5nL29013670; Thu, 17 Oct 2002 22:49:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I5nLlM013669; Thu, 17 Oct 2002 22:49:21 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I5nI29013662 for ; Thu, 17 Oct 2002 22:49:18 -0700 (PDT) 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 g9I5nOMq011890 for ; Thu, 17 Oct 2002 22:49:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02123 for ; Thu, 17 Oct 2002 22:49:18 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9I5mls00452; Fri, 18 Oct 2002 08:48:47 +0300 Date: Fri, 18 Oct 2002 08:48:46 +0300 (EEST) From: Pekka Savola To: "Nick 'Sharkey' Moore" cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... In-Reply-To: <20021018084132.A7282@dwerryhouse.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Oct 2002, Nick 'Sharkey' Moore wrote: > On Thu, Oct 17, 2002 at 12:54:34PM +0300, Pekka Savola wrote: > > > > Optimistic DAD is a useful optimization because DAD is far more > > likely to succeed than fail, by a factor of at least 10,000,000,000 > > to one[SOTO]. This makes it worth a little disruption in the failure > > case to provide faster handovers in the successful case, as long as > > the disruption is recoverable. > > > > ==> this is totally, and completely wrong. [SOTO] only provide analysis > > in *some* cases, in particular autoconfigured vs privacy addresses. > > I see what you mean. I need to make it clear that [SOTO] and I are > referring to strongly random addresses ... this is a requirement > for my Optimistic DAD draft anyway for exactly this reason. Yep. > Do you this it is fair to say: > > DAD is far more likely to succeed than fail FOR RANDOMLY > AUTOCONFIGURED ADDRESSES, by a factor of at least 10,000,000,000 > to one[SOTO]. This sounds rather good, using the lower case, of course. What's included in "randomly autoconfigured addresses" is a bit blurry, though. Is it RFC3041 only? Does it include EUI64-based schemes, etc? > Do you think it would be advisable for me to add: > > Optimistic DAD MUST NOT be used for manually configured addresses > > ... because as you point out, manually configured addresses are > far more likely to fail and being a MobileIP type I'm mainly > interested in configuring CoAs anyway. That is sounds good to me. I'd also add a line of reasoning behind that, like: Optimistic DAD MUST NOT be used for manually configured addresses, as those are much, much more likely to have collisions. > > For manually assigned addresses, I believe the ratio is closer > > to 1:10 or 1:100 (unmeasurable, of course). > > I'd be really interested to know if anyone has any indicative > figures on MAC address collision: it is inevitable that somewhere > out there there are two adaptors with the same MAC address due > to human frailties, but how many? I don't have figures but Francis Dupont reported this happening once to him. It should also be noted that people *do* change MAC addresses manually (possibly leading to clashes), e.g. in internet exchange points per policy and in e.g. access lines (e.g. xDSL) if ISP expects to see only one MAC address. But these aren't usually a shared medium or config'd addresses are used, so this may not be that big a problem. Vendors who ship e.g. 4-port Ethernet adapters (e.g some Sun products) with the same mac address in each port are problematic of course (and this isn't the first time -- switches usually don't like it:-). If you connect two ports to the same segment.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 00:12:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I7CN29013819; Fri, 18 Oct 2002 00:12:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I7CN8k013818; Fri, 18 Oct 2002 00:12:23 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I7CJ29013811 for ; Fri, 18 Oct 2002 00:12:20 -0700 (PDT) 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 g9I7CRMq023475 for ; Fri, 18 Oct 2002 00:12:27 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09813 for ; Fri, 18 Oct 2002 00:12:21 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9I7BnKX023916; Fri, 18 Oct 2002 09:11:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 18 Oct 2002 09:11:49 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B92@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Nick 'Sharkey' Moore'" , "Hesham Soliman (EAB)" Cc: "Bound, Jim" , "Alper E. YEGIN" , alh-ietf@tndh.net, Pekka Savola , ipng@sunroof.eng.sun.com Subject: RE: Optimistic DAD draft ... Date: Fri, 18 Oct 2002 09:11:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Why not? I think it is scalable to that level simply > > because you can plug more anchor points as you see > > fit. it's as scalable as HAs are in MIPv6. > > My main concern would be issues to do with the MAP information > propagation, and the MAP selection algorithm ... I think there's > some common ground between the tactics of HMIP and the FMIP > three-party-handover and I suspect the best solution is in that > region somewhere ... => I guess, w're on the wrong list for this discussion. But I don't understand your concern about "propagation". In Jim's case, you're not likely to use Dynamic MAP discovery. The most likely way is manual configuration of ARs. > > => What you're doing (optimistic DAD) can be combined > > with Fast Handovers to completely eliminate movement > > detection delay. [...] > > => My very initial effort (with Karim) with Fast > handovers was aimed > > at: anticipation + optimistic DAD + HMIPv6. > > It's tricky getting anticipation signalling out of most 802.11 > drivers, but we've had success getting L2 to signal L3 that it has > just reassociated, causing L3 to RS. Greg Daley has more information > here, I'm sure he'll chip in when he gets back to town ... => Anticipation is not bound to 802.11, it can also happen on the network side in other link layers. I agree that it is not supported by all cards as you guys keep telling me :) Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 00:35:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I7ZW29013971; Fri, 18 Oct 2002 00:35:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I7ZWpX013970; Fri, 18 Oct 2002 00:35:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I7ZT29013963 for ; Fri, 18 Oct 2002 00:35:29 -0700 (PDT) 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 g9I7ZaPG010793 for ; Fri, 18 Oct 2002 00:35:36 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02112 for ; Fri, 18 Oct 2002 01:35:24 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id DCF81146D2; Fri, 18 Oct 2002 17:35:19 +1000 (EST) Date: Fri, 18 Oct 2002 17:35:19 +1000 From: "Nick 'Sharkey' Moore" To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018173518.A9635@dwerryhouse.com.au> References: <20021018084132.A7282@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Fri, Oct 18, 2002 at 08:48:46AM +0300 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 18, 2002 at 08:48:46AM +0300, Pekka Savola wrote: > > This sounds rather good, using the lower case, of course. Of course. I'll clarify the details for -01. Thanks for your feedback. > I don't have figures but Francis Dupont reported this happening once to > him. > It should also be noted that people *do* change MAC addresses manually > (possibly leading to clashes) NCD Xterms come to mind too, although these are unlikely to be seen on Mobile Networks Of The Future :-) -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 01:01:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I81429014167; Fri, 18 Oct 2002 01:01:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I8135p014166; Fri, 18 Oct 2002 01:01:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I81029014159 for ; Fri, 18 Oct 2002 01:01:00 -0700 (PDT) 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 g9I817Mq004850 for ; Fri, 18 Oct 2002 01:01:07 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04248 for ; Fri, 18 Oct 2002 02:01:01 -0600 (MDT) 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 JAA01573 for ; Fri, 18 Oct 2002 09:00:56 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:X4a4ha98y+sMHz69+Df2EsSOpHP7Baut@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9I80oWX014111 for ; Fri, 18 Oct 2002 09:00:50 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g9I80oH31961 for ipng@sunroof.eng.sun.com; Fri, 18 Oct 2002 09:00:50 +0100 Date: Fri, 18 Oct 2002 09:00:50 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Message-ID: <20021018080050.GK31335@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20021017014040.B8106@edi-view1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Oct 17, 2002 at 01:11:18PM +0300, Pekka Savola wrote: > > Yes, I believe the above draft is a good, simple starting point. > > There are still some unnecessary assumptions and extra text, I'll send > specific comments later. It seems that if you will trust RA's to build your address and select a default router, then having DNS info (not just server IP) in the RA is at first approximation a reasonable method (with obvious caveats). There seem to be many methods applied to discovery in many IPv6 tools, be it DNS discovery, ISATAP router discovery, etc... e.g. by anycast address by router advertisement piggyback by well-known name by well-known site-local unicast address by well-known site-local multicast address by DHCPv6 by Service Location Protocol by ... none of which may necessarily be secure. It seems that DNS would be the only additional service required for discovery via RA(?), but is there any merit to encouraging consistency in what other discovery tools use? (e.g. it would maybe seem odd to have each method used by different tools and to have to support them all, or is that seen as preferable for flexibility?) A review against existing proposals might be interesting? Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 01:22:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I8Ma29014293; Fri, 18 Oct 2002 01:22:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I8Makc014292; Fri, 18 Oct 2002 01:22:36 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I8MW29014285 for ; Fri, 18 Oct 2002 01:22:32 -0700 (PDT) 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 g9I8MdMq008292 for ; Fri, 18 Oct 2002 01:22:39 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15393 for ; Fri, 18 Oct 2002 02:22:34 -0600 (MDT) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id KAA17947; Fri, 18 Oct 2002 10:22:33 +0200 (MEST) Received: (from ignatios@localhost) by newton.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA08250; Fri, 18 Oct 2002 10:21:57 +0200 (CEST) Date: Fri, 18 Oct 2002 10:21:57 +0200 From: Ignatios Souvatzis To: "Nick 'Sharkey' Moore" Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018102157.A7718@newton.cs.uni-bonn.de> Reply-To: ipng@sunroof.eng.sun.com References: <20021015125759.B23137@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021015125759.B23137@dwerryhouse.com.au>; from sharkey@zoic.org on Tue, Oct 15, 2002 at 12:58:00PM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 15, 2002 at 12:58:00PM +1000, Nick 'Sharkey' Moore wrote: > We've kicked the idea around a little on mobile-ip, > and I've formalized my thoughts into an internet draft, > which should get published soon. In the meantime, you can > find it at > (tentatively titled draft-moore-ipv6-optimistic-dad-00). I've just looked at http://www.ctie.monash.edu.au/ipv6/draft-moore-ipv6-optimistic-dad-00.txt I've not decided yet whether this is a good idea at all (long thread to read), but there is a terminology error that should be corrected before use: 2.3 Address Generation [...] * A randomly generated address SHOULD have the Universal/Local bit and the Individual/Group bit set to 0 to indicate a locally scoped Unicast address (see [RFC2373]). s/locally scoped/not globally unique/ Regards, Ignatios Souvatzis --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPa/EGzCn4om+4LhpAQH4Qwf/Qsti2WhVnzjtbyVWZID9JDL/JeNsmlDb ETbtGdt3NPAB+KYsDbwwMV5eKuGjyy4TCzQHK2ZKzgCqnSFsB7MDN846pMiZBBK3 2mbWl09WOwMZParaioa4jo0dYdm0SJTDjoReOPw3lv4RVgsxxfbTqHUwRK87Ay6B u8zQBI1nMbMocWZmmEe3+J3Wtyon2xU8RbXI8WYalJ33X8/mG9/7UUlVlMfe1tIs Q23KxUwyBggLcyQmW+QSxNB/3Y+8CzbTJSjzWfd2Gy2NE2YoU9Sek5MOl62q3Pdy Md7OR4tTy7UW33lX5fHGp0ZiaC4Tu42hPt3WvDQR/8DhGgdb9Y+dkg== =NGaM -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 01:58:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I8wR29014517; Fri, 18 Oct 2002 01:58:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I8wR3l014516; Fri, 18 Oct 2002 01:58:27 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I8wN29014509 for ; Fri, 18 Oct 2002 01:58:24 -0700 (PDT) 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 g9I8wUMq013232 for ; Fri, 18 Oct 2002 01:58:30 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08038 for ; Fri, 18 Oct 2002 02:58:24 -0600 (MDT) 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 JAA02284 for ; Fri, 18 Oct 2002 09:58:23 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:QPAXBbESokX3F9c7YONzgvnEqq477vZ7@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9I8wIWX023943 for ; Fri, 18 Oct 2002 09:58:18 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g9I8wIh32623 for ipng@sunroof.eng.sun.com; Fri, 18 Oct 2002 09:58:18 +0100 Date: Fri, 18 Oct 2002 09:58:18 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021018085817.GR31335@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20021018084132.A7282@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 18, 2002 at 08:48:46AM +0300, Pekka Savola wrote: > > > I'd be really interested to know if anyone has any indicative > > figures on MAC address collision: it is inevitable that somewhere > > out there there are two adaptors with the same MAC address due > > to human frailties, but how many? > > I don't have figures but Francis Dupont reported this happening once to > him. I believe in some cases some cheap "clone" NICs would be mass-produced with the same MAC address, (the cloner doesn't care to honour the uniqueness) but hopefully this is rare. However, the units may be likely to end up at one site if bulk-bought from a reseller. There are three levels of probability - the random/privacy addresses across all 64 bits, the EUI-64 addresses (where due to vendor MAC prefix pools only the lower 24 bits may change) and manual addresses. > Vendors who ship e.g. 4-port Ethernet adapters (e.g some Sun products) > with the same mac address in each port are problematic of course (and this > isn't the first time -- switches usually don't like it:-). If you connect > two ports to the same segment.. Is that common? Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 02:03:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I93e29014587; Fri, 18 Oct 2002 02:03:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I93efe014586; Fri, 18 Oct 2002 02:03:40 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I93a29014579 for ; Fri, 18 Oct 2002 02:03:36 -0700 (PDT) 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 g9I93hMq013931 for ; Fri, 18 Oct 2002 02:03:43 -0700 (PDT) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10068 for ; Fri, 18 Oct 2002 03:03:35 -0600 (MDT) Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6/8.12.6) with ESMTP id g9I93XsT036350 for ; Fri, 18 Oct 2002 18:03:33 +0900 (JST) X-Authentication-Warning: ns.64translator.com: Host [10.21.32.3] claimed to be bahamas.64translator.com Received: from localhost.localdomain ([10.21.33.215]) by bahamas.64translator.com (8.11.6/8.11.6) with SMTP id g9I93Su13759 for ; Fri, 18 Oct 2002 18:03:28 +0900 (JST) Date: Fri, 18 Oct 2002 18:03:26 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: newest TAHI conformance test tool is available Message-Id: <20021018180326.26be457b.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, folks. Now, we (TAHI Project) have released version 2.0 of conformance test suites. You can get them from our web site. http://www.tahi.org/release/ And our contact point is . Changes from Release 1.3 ---------------------------------------------------------------- * New tests: o + MIP6 for MN tests contributed by IBM Corporation + MIP6 for CN tests + MIP6 for HA tests o + IPv6 Specification for LCNA + ICMPv6 for IPv6 Specification for LCNA + Neighbor Discovery for LCNA + IPv6 Stateless Address Autoconfiguration for LCNA + IPv6 Path MTU Discovery for LCNA + IPSec AH and ESP for IPv6 for LCNA + IPSec AH and ESP for IPv6(UDP) for LCNA + IPSec AH and ESP for IPv6(granularity) for LCNA * New targets: o Add remote files + usagi-i386/mip6EnableMN.rmt, mipl/mip6EnableMN.rmt contributed by IBM Corporation o support MIP6 ID-15 Thanks. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 02:05:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I95229014646; Fri, 18 Oct 2002 02:05:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I952qi014645; Fri, 18 Oct 2002 02:05:02 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I94v29014632 for ; Fri, 18 Oct 2002 02:04:58 -0700 (PDT) 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 g9I955Mq014127 for ; Fri, 18 Oct 2002 02:05:05 -0700 (PDT) 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 CAA27772 for ; Fri, 18 Oct 2002 02:04:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7C30B4B22; Fri, 18 Oct 2002 18:04:53 +0900 (JST) To: Tim Chown Cc: ipng@sunroof.eng.sun.com In-reply-to: tjc's message of Fri, 18 Oct 2002 09:58:18 +0100. <20021018085817.GR31335@login.ecs.soton.ac.uk> 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: Optimistic DAD draft ... From: itojun@iijlab.net Date: Fri, 18 Oct 2002 18:04:53 +0900 Message-Id: <20021018090453.7C30B4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Vendors who ship e.g. 4-port Ethernet adapters (e.g some Sun products) >> with the same mac address in each port are problematic of course (and this >> isn't the first time -- switches usually don't like it:-). If you connect >> two ports to the same segment.. >Is that common? for load sharing (like having 400Mbps bandwidth rather than 100Mbps) yes. 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 Fri Oct 18 02:57:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I9v529015070; Fri, 18 Oct 2002 02:57:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9I9v4XJ015069; Fri, 18 Oct 2002 02:57:04 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9I9v129015062 for ; Fri, 18 Oct 2002 02:57:01 -0700 (PDT) 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 g9I9v8Mq021253 for ; Fri, 18 Oct 2002 02:57:08 -0700 (PDT) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25168 for ; Fri, 18 Oct 2002 02:57:02 -0700 (PDT) Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6/8.12.6) with ESMTP id g9I9v0sT036526 for ; Fri, 18 Oct 2002 18:57:00 +0900 (JST) X-Authentication-Warning: ns.64translator.com: Host [10.21.32.3] claimed to be bahamas.64translator.com Received: from localhost.localdomain ([10.21.33.215]) by bahamas.64translator.com (8.11.6/8.11.6) with SMTP id g9I9utu14063 for ; Fri, 18 Oct 2002 18:56:55 +0900 (JST) Date: Fri, 18 Oct 2002 18:56:53 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: Re: newest TAHI conformance test tool is available Message-Id: <20021018185653.17b0a462.Yukiyo.Akisada@jp.yokogawa.com> In-Reply-To: <20021018180326.26be457b.Yukiyo.Akisada@jp.yokogawa.com> References: <20021018180326.26be457b.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, folks. I have to say these are just our too old works, it was the results of last year. It means that TAHI doesn't continue to work around LCNA. On Fri, 18 Oct 2002 18:03:43 +0900 Yukiyo Akisada wrote: > Changes from Release 1.3 > ---------------------------------------------------------------- (snip) > + IPv6 Specification for LCNA > + ICMPv6 for IPv6 Specification for LCNA > + Neighbor Discovery for LCNA > + IPv6 Stateless Address Autoconfiguration for LCNA > + IPv6 Path MTU Discovery for LCNA > + IPSec AH and ESP for IPv6 for LCNA > + IPSec AH and ESP for IPv6(UDP) for LCNA > + IPSec AH and ESP for IPv6(granularity) for LCNA ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 03:59:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IAxm29015535; Fri, 18 Oct 2002 03:59:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IAxmn0015534; Fri, 18 Oct 2002 03:59:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IAxj29015527 for ; Fri, 18 Oct 2002 03:59:45 -0700 (PDT) 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 g9IAxqPG008635 for ; Fri, 18 Oct 2002 03:59:52 -0700 (PDT) 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 EAA29218 for ; Fri, 18 Oct 2002 04:59:46 -0600 (MDT) From: jarno.rajahalme@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 g9IAxQw08142 for ; Fri, 18 Oct 2002 13:59:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 18 Oct 2002 13:59:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 13:59:44 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on IPv6 Flow Label Last Call X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 13:59:43 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F9117571981A3@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on IPv6 Flow Label Last Call Thread-Index: AcJ1RX7GnlsJ/r6KQ2Kp8t9U8hKmUgBODZiA To: , X-OriginalArrivalTime: 18 Oct 2002 10:59:44.0700 (UTC) FILETIME=[7781DFC0:01C27695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9IAxj29015528 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Happy to see the WG Last Call finally announced :-) Bob Hinden wrote: > The IPv6 w.g. chairs believe there are some important open > issues that they > would like to see the working group discuss as part of the > working group > last call on the "IPv6 Flow Label Specification" > . > > The current draft allows flow labels to be used in ways that go beyond the > consensus that was reached when the working group agreed to make this > document a working group document. The draft is where the WG consensus should be documented, as it has been continuously revised based on the comments received in both the meetings and on the list. At least I have not been aware of any other documentation of the WG consensus on this topic. Naturally the draft will be further revised based on the comments and consensus on this list during the WG Last Call period. > This consensus was that the flow label would be set by a source node > to label a set of packets (with same source and destination addresses) > that the source wanted to be treated as a flow. > The flow label in this definition did not have any defined > structure. > The main application for this was to make it easier for other > nodes to recognize flows without having to search to one or more headers to > find the transport port numbers. I may be too careful here, and am sorry if the following is unwarranted. "Recognize" is clearly out of the consensus, if it means anything else that "classify". Also it has been long standing consensus that there should be no requirement to have 1:1 mapping between transport connections and IPv6 flows, with the explicit meaning that the flow label is not mandated to be a transformation of the transport header information. What this means is that classifying on the traditional 5-tuple (addresses, transport protocol, port numbers) and the 3-tuple of (flow label, addresses) WILL in some cases result to different results. So the main and only application of the flow label field is to enable efficient flow classification independently of the upper headers. The source node defines what constitutes a flow by labeling the packets. It is free to put multiple transport connections to the same flow, or to split a single transport connection between multiple flows. One possible interpretation for "recognizing flows without having to search ... the transport port numbers" is that the flow label based classification would be expected to map 1:1 with port number based classification, even so that the flow label based flows would be "recognized" by first classifying on the port numbers, creating flow state out of that based on the flow label that happened to be in the same packet, and then later classifying on the addresses and flow label only, with the expectation that the classification results be the same as would have been for port based classification. If the chairs have the intention to drive the solution to the direction described above, it would be fair to say so, so that the necessary discussion can take place on the list as part of the Last Call process. The first time I saw the above kind of scenario being proposed on the list was a couple of months ago, roughly half a year after the decision to make our draft a WG work item. I'm sorry if I indeed was just too paranoid about this, and this is really a non-issue for all of us. > The current draft has a number of > features that go beyond this model and permit many other modes. Examples > include: > Some earlier attempts to specify the flow label usage have failed due to trying to narrow down the usage scenarios resulting to endless discussions of issues secondary to the flow label specification itself. To enable building consensus on the specification, the authors have aimed at minimal requirements that enable the intended uses of the flow label. Our intention has not been to prohibit any other (maybe unknown) modes/models. I still believe the specification should specify the absolutely needed minimal requirements, and additional helpful guidance where necessary. > - Allowing for other standard specifications to define > properties and/or > structure of the flow label field. This is referring to the sentence: "IPv6 nodes MUST NOT assume mathematical or other non-standardized properties of the Flow Label values assigned by source nodes." Currently, no such standardized properties exist. Any such standard would necessarily need to be approved by the IPv6 WG and IESG in future. But if this is seen as an issue, I would be happy to change the referred sentence to (rest of the paragraph shown for context): "IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key." > - A strong focus on the assignment of flow label via > signaling protocols. I do not see this. There is strong focus on distribution of the flow state via flow state establishment methods, that may be signaling methods, manual configuration, etc. References to signaling methods like RSVP and SDP are there to provide helpful guidance to work being conducted in NSIS, for example. In section 4. there is the highest precedence rule for assigning packets to flows, that is specifying a signaling method with a MAY. The motivation for the precedence ordering in that section is that there should be default behavior of the TCP/IP stack (4), that should be overridden by applications having more knowledge of their flows (2), that should be overridden by any specific configuration on the source host (3), and that should finally be overridden by signaling based methods, since they provide the most "current" or "timely" knowledge of what packets should belong to which flow. This order represents the understanding of the authors on how the assignment of packets to flows "works". However, we are open for any comments on this area as well. I should also note that the assignment of a specific flow label value to the flow is somewhat orthogonal to the above ("assignment of packets to flows"). Also in (1) the source will most likely pick a value that is then used part of the classifier, that is then configured in the relevant nodes. > - Allowing a specific flow label value to be assigned via > a signaling > protocol to identify flows with different source and destination > addresses. > As long as applications are allowed to specify what flow label values should be used with specific flows, the above is allowed as well (the signaling protocol being utilized by the application in this case). To not allow the above necessarily means to only use random (at least from the viewpoint of the application) flow label values for each new flow. We should not make random assignment mandatory just to prevent upper layers to build higher-layer constructs based on flows, especially when at least some of those constructs can be seen to be beneficial. The RSVP Wildcard-Filter reservation style is the example of this we have in the draft currently (2nd to last paragraph on section 4, on page 5). > The draft may be trying to accommodate uses of the flow label > that were not > agreed to by the working group. > It is my opinion that it would be futile to even try to agree on the all possible uses of the flow label field in the working group, at least now. For example, the non-mutability requirement would allow people to build end-to-end protocols with application multiplexing without using any transport headers by using the flow label as the multiplexer. While there may be many reasons why such a thing would be a Bad Idea, the only real consensus possible for this WG is "so what, we don't care". The only way to really prohibit the end-to-end usage would be to make the field explicitly mutable, which I do not think we can do without harming the usage as a well defined classifier. What I mean with the above that we should not worry what uses someone may come up with as long as they do not interfere with the use as a flow classifier. (It could also be added that if none of the flow endpoints wants to have the flow classified, there shouldn't be any reason to not allow even weirder usages between consenting hosts.) > There are a number of other areas in the draft that need additional > discussion and/or clarification. These include: > > - No default time out for the life time for specific flow > label values. The requirement (5) (section 5) is in there to mandate flow state clean- up. If flow state establishment method requires a time out, then it would be up to that method to define the time out. Some, e.g. configuration based methods, may not require a specific time out value at all. > - No requirement that signaling mechanisms must include a lifetime > when providing flow label setup information. This could be added. Currently it states that (for methods in general) both soft- and hard-state methods are possible. This could be refined so that dynamic methods (including signaling based methods, algorithmic methods) would need to specify a time-out, while static methods (e.g. configuration based) should not. > - No default mechanisms if flow label values requested via > a signaling > mechanisms conflict with existing flow label values. It would be the function of the signaling mechanism itself to define the error response mechanism (currently a SHOULD in (6) of section 5). Maybe that should be a MUST instead? I don't see what a default mechanism could add here? It could be hard to coordinate the implementations between a signaling mechanism (e.g. in the user space) and a separate default error response mechanism (possibly in the kernel). > - Security considerations need to discuss the impact of > labeling flows > of encrypted traffic. That is already done to some extent. Currently all we have is: "The use of the Flow Label field enables flow classification also in the presence of encryption of IPv6 payloads. This allows the transport header values to remain confidential, which may lessen the possibilities for some forms of traffic analysis." Also, in the -02 version we had the following sentence in the beginning of the Security Considerations: "Anything that facilitates flow classification also increases the vulnerability to traffic analysis." That was removed based on the feedback received. Should we move that back in? Is there something else the chairs see missing? > > The chairs would like to see these issues discussed by the > working group in > the last call. > > Bob Hinden, Steve Deering, Margaret Wasserman > Regards, Jarno -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 08:12:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IFCM29016377; Fri, 18 Oct 2002 08:12:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IFCMvD016376; Fri, 18 Oct 2002 08:12:22 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IFCI29016369 for ; Fri, 18 Oct 2002 08:12:18 -0700 (PDT) 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 g9IFCPMq010824 for ; Fri, 18 Oct 2002 08:12:25 -0700 (PDT) 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 JAA21584 for ; Fri, 18 Oct 2002 09:12:19 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29565; Fri, 18 Oct 2002 11:10:04 -0400 (EDT) Message-Id: <200210181510.LAA29565@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-send@standards.ericsson.net, ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-psreq-00.txt Date: Fri, 18 Oct 2002 11:10:03 -0400 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 Securing Neighbor Discovery Working Group of the IETF. Title : IPv6 Neighbor Discovery trust models and threats Author(s) : P. Nikander Filename : draft-ietf-send-psreq-00.txt Pages : 13 Date : 2002-10-17 The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms MAY be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertient to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neigbor Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-psreq-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-psreq-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-18111857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-psreq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-psreq-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-18111857.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 Oct 18 10:19:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHJJ29016900; Fri, 18 Oct 2002 10:19:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IHJJHS016899; Fri, 18 Oct 2002 10:19:19 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHJG29016892 for ; Fri, 18 Oct 2002 10:19:16 -0700 (PDT) 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 g9IHJMMq015981 for ; Fri, 18 Oct 2002 10:19:23 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28171 for ; Fri, 18 Oct 2002 10:19:17 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 295D6104D; Fri, 18 Oct 2002 12:19:06 -0500 (CDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id DA53812FD; Fri, 18 Oct 2002 12:19:01 -0500 (CDT) Message-ID: <3DB04281.8090909@hp.com> Date: Fri, 18 Oct 2002 13:18:57 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... References: <20021015125759.B23137@dwerryhouse.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick I haven't made up my mind yet about this draft, but here are some comments. - Sections 2.1 and 2.2 are not very clear. For example, in section 2.2 there are two bullets that modify section 5.4.3, but these 2 bullets are very ambigiouse as to what parts of [rfc2462 sec. 5.4.3] they apply to. It would be better if the draft spelled out the particular modified behavior. - Section 3.1 of the draft states: > ... Since the Optimistic Node already has the link-layer > address of the router, and the router now has the link-layer address > of the Optimistic Node, communications can begin immediately. Where are these link-layer addresses taken from? The router will ignore both NS and NA for the following reasons: - NS is send without the Source Link-Layer Address option. - NA is sent with the O-bit = 0. If the router does not have an entry for this address (most likely), it "SHOULD" ignore the NA (2461). The only place so far the node can get the address of the router is from the RA, but Source Link-Layer Address option is optional in RAs (it's a MAY in 2462). - Section 3.2: For the simple case, there is a very minor effect on the operation of non-optimistic nodes. An optimistic node will force the state of all REACHABLE entries to transition to STALE and may force NUD. This is a very minor effect, but it should be noted. Also, the initial delay of the first NUD probe is 5 seconds which is rather substantial amount of time that the packets may be blackholed in the case of proxy NAs. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 10:32:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHWL29016981; Fri, 18 Oct 2002 10:32:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IHWKHu016980; Fri, 18 Oct 2002 10:32:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHWH29016973 for ; Fri, 18 Oct 2002 10:32:17 -0700 (PDT) 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 g9IHWNPG024286 for ; Fri, 18 Oct 2002 10:32:24 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15503 for ; Fri, 18 Oct 2002 11:32:17 -0600 (MDT) Message-ID: <006e01c276cc$1d61cd70$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Nick 'Sharkey' Moore" , "Pekka Savola" Cc: References: <20021015125759.B23137@dwerryhouse.com.au> <20021018084132.A7282@dwerryhouse.com.au> Subject: Re: Optimistic DAD draft ... Date: Fri, 18 Oct 2002 10:30:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > For manually assigned addresses, I believe the ratio is closer > > to 1:10 or 1:100 (unmeasurable, of course). > > I'd be really interested to know if anyone has any indicative > figures on MAC address collision: it is inevitable that somewhere > out there there are two adaptors with the same MAC address due > to human frailties, but how many? Another possible source of collision would be people changing their mac address each time they change access network for privacy reasons (to prevent one form of tracking). alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 10:49:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHnb29017238; Fri, 18 Oct 2002 10:49:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IHnaJN017237; Fri, 18 Oct 2002 10:49:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHnX29017230 for ; Fri, 18 Oct 2002 10:49:33 -0700 (PDT) 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 g9IHnePG029823 for ; Fri, 18 Oct 2002 10:49:40 -0700 (PDT) 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 LAA24268 for ; Fri, 18 Oct 2002 11:49:33 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4F7FBA5B; Fri, 18 Oct 2002 13:49:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Oct 2002 13:49:31 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Optimistic DAD draft ... x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 13:49:31 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE95B4@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ2RuHQg57TS7J5QP6hSO+ooEQngAAh5ixQ From: "Bound, Jim" To: "Nick 'Sharkey' Moore" Cc: "James Kempf" , "Alper E. YEGIN" , "Pekka Savola" , X-OriginalArrivalTime: 18 Oct 2002 17:49:31.0970 (UTC) FILETIME=[B6A98A20:01C276CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9IHnX29017231 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ahh I do that every day in engineering :--) Hey if you collide take a look at router renumbering spec for IPv6 :--) We have way to many specs to read I have no clue how the IESG keeps up with it all. That is why it's a full time job right there. Let alone all the other stuff they have to do. /jim > -----Original Message----- > From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] > Sent: Thursday, October 17, 2002 8:37 PM > To: Bound, Jim > Cc: James Kempf; Alper E. YEGIN; Pekka Savola; > ipng@sunroof.eng.sun.com > Subject: Re: Optimistic DAD draft ... > > > On Thu, Oct 17, 2002 at 06:24:24PM -0400, Bound, Jim wrote: > > Nick per hmip I rest my case :---) below. I don't have and opinion > > not my discipline but I would like to see James, Hesham, you, et al > > agree > > :----) How about for the greater good :--) > > Should our opinions collide, we'll reconfigure :-) > > I guess I'm working from a different angle to most, too: > "What is the minimum required for a useful fast, smooth > MIPv6" vs. "What is the most perfect system which is still > implementable". > > -----Nick > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 10:53:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHrN29017286; Fri, 18 Oct 2002 10:53:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9IHrMSE017285; Fri, 18 Oct 2002 10:53:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9IHrJ29017278 for ; Fri, 18 Oct 2002 10:53:19 -0700 (PDT) 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 g9IHrQPG001002 for ; Fri, 18 Oct 2002 10:53:26 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17837 for ; Fri, 18 Oct 2002 10:53:20 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9IHrAQ1003858; Fri, 18 Oct 2002 19:53:10 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 18 Oct 2002 19:53:10 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B98@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Vladislav Yasevich'" , "Nick 'Sharkey' Moore" Cc: ipng@sunroof.eng.sun.com Subject: RE: Optimistic DAD draft ... Date: Fri, 18 Oct 2002 19:53:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - Section 3.1 of the draft states: > > > ... Since the Optimistic Node already has the > link-layer > > address of the router, and the router now has the > link-layer address > > of the Optimistic Node, communications can begin immediately. > > Where are these link-layer addresses taken from? > > The router will ignore both NS and NA for the following reasons: > - NS is send without the Source Link-Layer Address option. > - NA is sent with the O-bit = 0. If the router does > not have an > entry for this address (most likely), it "SHOULD" > ignore the NA > (2461). > > The only place so far the node can get the address of > the router is from > the RA, but Source Link-Layer Address option is optional in RAs > (it's a MAY in 2462). ^^^^^ => You mean 2461 I guess. There is probably an implicit assumption about the use of Fast Handovers here. In that case the optimistic node can get this information before it moves. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 16:15:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9INFc29019136; Fri, 18 Oct 2002 16:15:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9INFcIG019135; Fri, 18 Oct 2002 16:15:38 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9INFP29019128 for ; Fri, 18 Oct 2002 16:15:35 -0700 (PDT) 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 g9INFVMq003380 for ; Fri, 18 Oct 2002 16:15:32 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23169 for ; Fri, 18 Oct 2002 17:15:26 -0600 (MDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9INEmot019462; Fri, 18 Oct 2002 16:14:48 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9INEltU000932; Fri, 18 Oct 2002 16:14:48 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (dhcp-171-71-62-38.cisco.com [171.71.62.38]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA16731; Fri, 18 Oct 2002 16:14:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20021018190705.0991d858@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Oct 2002 19:14:45 -0400 To: ipng@sunroof.eng.sun.com From: Chris Metz Subject: Reviewers for IEEE IC Special Issue Cc: users@ipv6.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looking for a few IPv6 folks to serve as reviewers of submitted papers for a special issue on IPv6 in IEEE Internet Computing due out in May/June 2003. Upside: early exposure to interesting IPv6 papers and I'll reciprocate the effort in the future :-) If interested contact Chris Metz at chmetz@cisco.com. Cheers ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 17:29:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J0T929019388; Fri, 18 Oct 2002 17:29:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9J0T9pD019387; Fri, 18 Oct 2002 17:29:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J0T629019380 for ; Fri, 18 Oct 2002 17:29:06 -0700 (PDT) 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 g9J0TCPG015542 for ; Fri, 18 Oct 2002 17:29:13 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03490 for ; Fri, 18 Oct 2002 17:29:07 -0700 (PDT) Message-ID: <021401c27706$5842b0f0$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pekka Savola" , "Nick 'Sharkey' Moore" Cc: References: Subject: Re: Optimistic DAD draft ... Date: Fri, 18 Oct 2002 17:26:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > 2) I'm not sure if this is the right approach. Something better suited > could be found, I believe, in adding functionality to first-hop routers' > ND cache behaviour; a router could answer directly which could be > interpreted like "don't use that address, I just recently saw it used here > by another node.. but if you're really sure you want it, perform DAD as > specified in RFC2461/2". This is the approach I've been looking at. But there is a problem. Nodes that implement the required ND extension can explicitely inform the router about their IP addresses. Router can learn about others (i.e., regular DAD hosts) via listening to multicast NSs for DAD. No problems so far... But when a router starts with no state (a new one, or rebooting after crash), it might never learn about regular nodes that have already done DAD. So, unless this problem is solved, the applicability of this solution is limited to networks where all nodes support the required extensions.. Any ideas? > Optimistic DAD is a useful optimization because DAD is far more > likely to succeed than fail, by a factor of at least 10,000,000,000 > to one[SOTO]. This makes it worth a little disruption in the failure > case to provide faster handovers in the successful case, as long as > the disruption is recoverable. > > ==> this is totally, and completely wrong. [SOTO] only provide analysis > in *some* cases, in particular autoconfigured vs privacy addresses. For > manually assigned addresses, I believe the ratio is closer to 1:10 or > 1:100 (unmeasurable, of course). I must be missing something.. How come this probability is so high? alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 18:22:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J1Ms29019668; Fri, 18 Oct 2002 18:22:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9J1MsS5019667; Fri, 18 Oct 2002 18:22:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J1Mn29019660 for ; Fri, 18 Oct 2002 18:22:50 -0700 (PDT) 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 g9J1MtPG025315 for ; Fri, 18 Oct 2002 18:22:56 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13156 for ; Fri, 18 Oct 2002 19:22:49 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 53A9B146D2; Sat, 19 Oct 2002 11:22:41 +1000 (EST) Date: Sat, 19 Oct 2002 11:22:41 +1000 From: "Nick 'Sharkey' Moore" To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021019112239.A12988@dwerryhouse.com.au> References: <20021015125759.B23137@dwerryhouse.com.au> <3DB04281.8090909@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DB04281.8090909@hp.com>; from Vladislav.Yasevich@hp.com on Fri, Oct 18, 2002 at 01:18:57PM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 18, 2002 at 01:18:57PM -0400, Vladislav Yasevich wrote: > > - Sections 2.1 and 2.2 are not very clear. For example, in > section 2.2 there are two bullets that modify section 5.4.3, > but these 2 bullets are very ambigiouse as to what parts of > [rfc2462 sec. 5.4.3] they apply to. It would be better if > the draft spelled out the particular modified behavior. Okay, I'll look into making this less ambiguous. The difficulty is that the changes are relatively small compared to the main text (eg, 2461/2462), and so I've tried to emphasize the changes rather than providing the full rules and making people work out the difference! > Where are these link-layer addresses taken from? > The router will ignore both NS and NA for the following reasons: > - NS is send without the Source Link-Layer Address option. > - NA is sent with the O-bit = 0. Well, more to the point, S=0. So if it doesn't have an entry, it will most likely ignore it. Hesham points out that this is probably an assumption of Fast Handovers type behaviour on my part: guilty as charged. There's nothing more effective than peer review to find your assumptions! In the Fast Handovers case, the router probably has some traffic waiting for the MN. I'll consider more carefully what will happen if this is not the case and post again on Monday. > The only place so far the node can get the address of the router is from > the RA, but Source Link-Layer Address option is optional in RAs > (it's a MAY in 2462). Ummm. Interesting. 2461 says "A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses.", but I'll admit I'd never considered it! > For the simple case, there is a very minor effect on the operation > of non-optimistic nodes. An optimistic node will force the state > of all REACHABLE entries to transition to STALE and may force NUD. > This is a very minor effect, but it should be noted. A NA with S=0,O=0 for a REACHABLE entry will have no effect on the entry according to the Appendix C state machine, and these are the only NAs which the ON will sent to All Nodes which Tentative. Admittedly an NA with S=1,O=0 will reset a REACHABLE entry to STALE, but why is the correspondent soliciting for a REACHABLE entry? (Or have I missed something elsewhere?) > Also, the initial delay of the first NUD probe is 5 seconds which is > rather substantial amount of time that the packets may be blackholed > in the case of proxy NAs. Yep. That's probably the worst outcome on the list, but I think it is acceptable as it is both unlikely (new connection on colliding address) and recoverable (by NUD). Thanks for your feedback ... you've certainly given me lots to think about on Monday! -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 18 18:36:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J1a129019739; Fri, 18 Oct 2002 18:36:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9J1a0Nc019738; Fri, 18 Oct 2002 18:36:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J1Zv29019731 for ; Fri, 18 Oct 2002 18:35:57 -0700 (PDT) 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 g9J1a3PG027450 for ; Fri, 18 Oct 2002 18:36:04 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16016 for ; Fri, 18 Oct 2002 19:35:57 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 81290146D2; Sat, 19 Oct 2002 11:35:51 +1000 (EST) Date: Sat, 19 Oct 2002 11:35:51 +1000 From: "Nick 'Sharkey' Moore" To: "Alper E. YEGIN" Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021019113550.B12988@dwerryhouse.com.au> References: <021401c27706$5842b0f0$696015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <021401c27706$5842b0f0$696015ac@AlperVAIO>; from alper@docomolabs-usa.com on Fri, Oct 18, 2002 at 05:26:22PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Oct 18, 2002 at 05:26:22PM -0700, Alper E. YEGIN wrote: > Pekka Savola wrote: > > > > 2) I'm not sure if this is the right approach. Something better suited > > could be found, I believe, in adding functionality to first-hop routers' > > ND cache behaviour; > > This is the approach I've been looking at. But there is a problem. [...] My colleague Greg Daley has been working on the same problem (eliminating DAD) from this direction: see draft-daley-ipv6-mcast-dad-01.txt > But when a router starts with no state (a new one, or rebooting > after crash), it might never learn about regular nodes that > have already done DAD. [...] So, unless this problem is solved, > the applicability of this solution is limited to networks where > all nodes support the required extensions.. Any ideas? This is my concern too: my aim with my draft was to work out a possible solution where totally unmodified nodes would interoperate correctly. > > For manually assigned addresses, I believe the ratio is closer to > > 1:10 or 1:100 (unmeasurable, of course). > > I must be missing something.. How come this probability is so high? Humans have remarkably lousy RNGs! I'm willing to believe Pekka on this one, because I've had many experiences with people assigning static V4 addresses ... "hey, we're up to x.y.z.57 aren't we? It's not in /etc/hosts on _my_ workstation ..." -----Nick "... hey, look, there's nothing registered to x.y.z.255 either!" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 19:39:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J2d229019958; Fri, 18 Oct 2002 19:39:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9J2d2FG019957; Fri, 18 Oct 2002 19:39:02 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J2cw29019949 for ; Fri, 18 Oct 2002 19:38:58 -0700 (PDT) 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 g9J2d3Mq017144 for ; Fri, 18 Oct 2002 19:39:04 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03825 for ; Fri, 18 Oct 2002 20:38:53 -0600 (MDT) From: Jonne.Soininen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9J2dcM02972 for ; Fri, 18 Oct 2002 21:39:38 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 21:38:52 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 19:38:52 -0700 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: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Date: Fri, 18 Oct 2002 19:38:51 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDB0F@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Thread-Index: AcJ2Cy+0vlSptp5qRk+aFuGl9qxriwBCnOkg To: , Cc: , X-OriginalArrivalTime: 19 Oct 2002 02:38:52.0354 (UTC) FILETIME=[A9538A20:01C27718] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9J2cx29019950 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > addres ses for DNS resolver" > > > Exactly, but this wouldn't have to be so. Introduction: > > Except for name resolution, all the other > services are usually described using names, not addresses, such as > smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping > reasons, a node needs to be configured with the IP address (and not > the name) of a DNS resolver. > > doesn't really require 3 DNS addresses. > > If one of the site-locals doesn't answer you, it's highly > unlikely that > the next one will (ie: not configured at all). If the second doesn't > answer either, it is almost unheard of if the third one does answer. I do not really see what harm would three addresses do. You may have networks that would have only one DNS server (small business or a home user with for a reason or another his own DNS server). However, in cases like ISPs or bigger businesses there may be multiple DNS servers configure. I believe this is the case even now. In short, I would argue that three is the right number. Cheers, Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@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 Sat Oct 19 02:12:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J9CV29020663; Sat, 19 Oct 2002 02:12:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9J9CVrl020662; Sat, 19 Oct 2002 02:12:31 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9J9CS29020655 for ; Sat, 19 Oct 2002 02:12:28 -0700 (PDT) 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 g9J9CaMq009649 for ; Sat, 19 Oct 2002 02:12:36 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22924 for ; Sat, 19 Oct 2002 02:12:30 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9J9CL211188; Sat, 19 Oct 2002 12:12:21 +0300 Date: Sat, 19 Oct 2002 12:12:20 +0300 (EEST) From: Pekka Savola To: Jonne.Soininen@nokia.com cc: mrw@windriver.com, , Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDB0F@mvebe001.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Oct 2002 Jonne.Soininen@nokia.com wrote: > > doesn't really require 3 DNS addresses. > > > > If one of the site-locals doesn't answer you, it's highly > > unlikely that > > the next one will (ie: not configured at all). If the second doesn't > > answer either, it is almost unheard of if the third one does answer. > > I do not really see what harm would three addresses do. You may have > networks that would have only one DNS server (small business or a home > user with for a reason or another his own DNS server). However, in cases > like ISPs or bigger businesses there may be multiple DNS servers > configure. I believe this is the case even now. > > In short, I would argue that three is the right number. Consider the case where the resolver has been upgraded to support this mechanism but the network isn't: this has an impact on 3 vs 0/1/2. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 19 13:36:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JKau29022254; Sat, 19 Oct 2002 13:36:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JKauTB022253; Sat, 19 Oct 2002 13:36:56 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JKar29022246 for ; Sat, 19 Oct 2002 13:36:53 -0700 (PDT) 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 g9JKb1Mq002247 for ; Sat, 19 Oct 2002 13:37:01 -0700 (PDT) Received: from mango.he.net (mango.he.net [66.220.11.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02386 for ; Sat, 19 Oct 2002 13:36:56 -0700 (PDT) Received: from leachlap5328 (pool-151-203-61-117.bos.east.verizon.net [151.203.61.117]) by mango.he.net (8.8.6/8.8.2) with SMTP id NAA01144 for ; Sat, 19 Oct 2002 13:36:53 -0700 Message-ID: <02a801c277af$2b195da0$0506330a@leachlap5328> From: "Kyle C Quest" To: Subject: IPV6_V6ONLY and a possible generic alternative Date: Sat, 19 Oct 2002 16:36:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The rfc2553bis draft introduces the IPV6_V6ONLY socket option to let applications limit the use of an ipv6 socket to ipv6 communication only. I think a better(more generic) solution would be a generic socket option which says "my family only". There could be "SO_ONEFAMILY" or similar generic socket option to do that. The idea is that if we have a socket and we want to restrict it to IPv6 or IPv4 (or some future IPvX) we'd have a way to do that. I don't know if this idea has been already discussed here... (I checked only the last couple of months). I'd like to know what people think about it. Thank you, Kyle C Quest -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 13:38:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JKck29022271; Sat, 19 Oct 2002 13:38:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JKckVR022270; Sat, 19 Oct 2002 13:38:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JKcg29022263 for ; Sat, 19 Oct 2002 13:38:42 -0700 (PDT) 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 g9JKcoPG023278 for ; Sat, 19 Oct 2002 13:38:51 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00704 for ; Sat, 19 Oct 2002 14:38:45 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9JKci7U142548 for ; Sat, 19 Oct 2002 16:38:44 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9JKcfcl111152 for ; Sat, 19 Oct 2002 16:38:42 -0400 Importance: Normal Sensitivity: Subject: IPv6 MIB Design team - new RFC2012 draft To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Kristine Adamson Date: Sat, 19 Oct 2002 16:38:41 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/19/2002 14:38:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about the tcpListenerEstablished MIB object in the June 2002 version of the new RFC2012 MIB draft. Is this counter only supposed to represent the number of connections that have transitioned to the established state for a Listener, or the number of connections in established state that have also been accepted for a Listener? 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 Sat Oct 19 14:00:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JL0329022417; Sat, 19 Oct 2002 14:00:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JL032Z022416; Sat, 19 Oct 2002 14:00:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JL0029022409 for ; Sat, 19 Oct 2002 14:00:00 -0700 (PDT) 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 g9JL08Mq004703 for ; Sat, 19 Oct 2002 14:00:08 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11561 for ; Sat, 19 Oct 2002 14:00:02 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA18461; Sat, 19 Oct 2002 23:59:52 +0300 Date: Sat, 19 Oct 2002 23:59:52 +0300 Message-Id: <200210192059.XAA18461@burp.tkv.asdf.org> From: Markku Savela To: kquest@unital.com CC: ipng@sunroof.eng.sun.com In-reply-to: <02a801c277af$2b195da0$0506330a@leachlap5328> (kquest@unital.com) Subject: Re: IPV6_V6ONLY and a possible generic alternative References: <02a801c277af$2b195da0$0506330a@leachlap5328> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Kyle C Quest" > > The rfc2553bis draft introduces the IPV6_V6ONLY socket option to let > applications limit the use of an ipv6 socket > to ipv6 communication only. I think a better(more generic) solution would be > a generic socket option which says "my family only". > There could be "SO_ONEFAMILY" or similar generic socket option to do that. > The idea is that if we have a socket > and we want to restrict it to IPv6 or IPv4 (or some future IPvX) we'd have a > way to do that. This is wrong direction to go. MOST applications should never care whether the communication is over IPv6 or IPv4 (or whatever IPvX). If a new IPv6 application is written, it should work the same with IPv4 and IPv6. If it does not, then I would consider application (and API) broken. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 14:17:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JLH629022538; Sat, 19 Oct 2002 14:17:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JLH58q022537; Sat, 19 Oct 2002 14:17:05 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JLH229022530 for ; Sat, 19 Oct 2002 14:17:02 -0700 (PDT) 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 g9JLHAMq006495 for ; Sat, 19 Oct 2002 14:17:10 -0700 (PDT) Received: from mango.he.net (mango.he.net [66.220.11.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15535 for ; Sat, 19 Oct 2002 14:17:05 -0700 (PDT) Received: from leachlap5328 (pool-151-203-61-117.bos.east.verizon.net [151.203.61.117]) by mango.he.net (8.8.6/8.8.2) with SMTP id OAA03244; Sat, 19 Oct 2002 14:17:01 -0700 Message-ID: <031e01c277b4$c5f4d250$0506330a@leachlap5328> From: "Kyle C Quest" To: "Markku Savela" Cc: References: <02a801c277af$2b195da0$0506330a@leachlap5328> <200210192059.XAA18461@burp.tkv.asdf.org> Subject: Re: IPV6_V6ONLY and a possible generic alternative Date: Sat, 19 Oct 2002 17:16:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Markku Savela" To: Cc: Sent: Saturday, October 19, 2002 4:59 PM Subject: Re: IPV6_V6ONLY and a possible generic alternative > > > From: "Kyle C Quest" > > > > The rfc2553bis draft introduces the IPV6_V6ONLY socket option to let > > applications limit the use of an ipv6 socket > > to ipv6 communication only. I think a better(more generic) solution would be > > a generic socket option which says "my family only". > > There could be "SO_ONEFAMILY" or similar generic socket option to do that. > > The idea is that if we have a socket > > and we want to restrict it to IPv6 or IPv4 (or some future IPvX) we'd have a > > way to do that. > > This is wrong direction to go. MOST applications should never care > whether the communication is over IPv6 or IPv4 (or whatever > IPvX). > > If a new IPv6 application is written, it should work the same with > IPv4 and IPv6. If it does not, then I would consider application > (and API) broken. > You bring up a good point... but why then rfc2553bis draft defines IPV6_V6ONLY option? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 19 14:26:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JLQg29022604; Sat, 19 Oct 2002 14:26:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JLQgCp022603; Sat, 19 Oct 2002 14:26:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JLQd29022593 for ; Sat, 19 Oct 2002 14:26:39 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9JLQk5I416140; Sat, 19 Oct 2002 14:26:46 -0700 (PDT) Date: Sat, 19 Oct 2002 14:26:45 -0700 From: Michael Hunter To: "Kyle C Quest" Cc: msa@burp.tkv.asdf.org, ipng@sunroof.eng.sun.com Subject: Re: IPV6_V6ONLY and a possible generic alternative Message-Id: <20021019142645.22f8d44a.michael.hunter@eng.sun.com> In-Reply-To: <031e01c277b4$c5f4d250$0506330a@leachlap5328> References: <02a801c277af$2b195da0$0506330a@leachlap5328> <200210192059.XAA18461@burp.tkv.asdf.org> <031e01c277b4$c5f4d250$0506330a@leachlap5328> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 19 Oct 2002 17:16:20 -0400 "Kyle C Quest" wrote: [...] > > This is wrong direction to go. MOST applications should never care > > whether the communication is over IPv6 or IPv4 (or whatever > > IPvX). > > > > If a new IPv6 application is written, it should work the same with > > IPv4 and IPv6. If it does not, then I would consider application > > (and API) broken. > > > > You bring up a good point... but why then rfc2553bis draft defines > IPV6_V6ONLY option? > >From 2553bis: An example use of this option is to allow two versions of the same server process to run on the same port, one providing service over IPv6, the other providing the same service over IPv4. So it can be seen as a transition mechanism. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 15:32:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JMWn29023007; Sat, 19 Oct 2002 15:32:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JMWnv0023006; Sat, 19 Oct 2002 15:32:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JMWj29022999 for ; Sat, 19 Oct 2002 15:32:45 -0700 (PDT) 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 g9JMWrPG004434; Sat, 19 Oct 2002 15:32:53 -0700 (PDT) Received: from mango.he.net (mango.he.net [66.220.11.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03252; Sat, 19 Oct 2002 15:32:48 -0700 (PDT) Received: from leachlap5328 (pool-151-203-61-117.bos.east.verizon.net [151.203.61.117]) by mango.he.net (8.8.6/8.8.2) with SMTP id PAA07198; Sat, 19 Oct 2002 15:32:45 -0700 Message-ID: <035401c277bf$5af771a0$0506330a@leachlap5328> From: "Kyle C Quest" To: "Michael Hunter" Cc: , References: <02a801c277af$2b195da0$0506330a@leachlap5328><200210192059.XAA18461@burp.tkv.asdf.org><031e01c277b4$c5f4d250$0506330a@leachlap5328> <20021019142645.22f8d44a.michael.hunter@eng.sun.com> Subject: Re: IPV6_V6ONLY and a possible generic alternative Date: Sat, 19 Oct 2002 18:32:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >[...] > >From 2553bis: > An example use of this option is to allow two versions of the same > server process to run on the same port, one providing service over IPv6, > the other providing the same service over IPv4. > > So it can be seen as a transition mechanism. > > mph > I was trying to say that the generic alternative to IPV6_V6ONLY does not introduce a completly new functionality (it extends/generalizes the functionality that's there for a reason). There has been a discussion about IPV6_V6ONLY option when the ability for IPv6 applications to interoperate with IPv4 application was implemented in Linux IPv6 stack (earlier this month). It seems better (more correct) to have a generic option to accomplish the same task. Kyle -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 15:56:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JMug29023109; Sat, 19 Oct 2002 15:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JMugKb023108; Sat, 19 Oct 2002 15:56:42 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JMuc29023101 for ; Sat, 19 Oct 2002 15:56:39 -0700 (PDT) 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 g9JMulMq015248 for ; Sat, 19 Oct 2002 15:56:47 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02658 for ; Sat, 19 Oct 2002 16:56:41 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 15:56:39 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 15:56:38 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 19 Oct 2002 15:56:39 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 15:56:39 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 15:56:38 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Sat, 19 Oct 2002 15:56:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 MIB Design team - new RFC2012 draft Date: Sat, 19 Oct 2002 15:56:37 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10874516F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 MIB Design team - new RFC2012 draft Thread-Index: AcJ3sPOgPzUXCx/QTqOyvMTsVq4hdQAEZVNQ From: "Dave Thaler" To: "Kristine Adamson" , X-OriginalArrivalTime: 19 Oct 2002 22:56:38.0533 (UTC) FILETIME=[C829AB50:01C277C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9JMud29023102 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Kristine Adamson [mailto:adamson@us.ibm.com] > > I have a question about the tcpListenerEstablished MIB object in the June > 2002 version of the new RFC2012 MIB draft. Is this counter only supposed > to represent the number of connections that have transitioned to the > established state for a Listener, or the number of connections in > established state that have also been accepted for a Listener? I'm not sure whether I understand your question. Are you asking whether it counts how many have ever transitioned to established vs the number currently in established state? If so, the answer is the former, since this is a Counter and not a Gauge. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 16:22:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNMC29023271; Sat, 19 Oct 2002 16:22:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JNMCmj023270; Sat, 19 Oct 2002 16:22:12 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNM829023263 for ; Sat, 19 Oct 2002 16:22:08 -0700 (PDT) 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 g9JNMHMq017660 for ; Sat, 19 Oct 2002 16:22:17 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05508 for ; Sat, 19 Oct 2002 17:22:11 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 16:22:12 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 19 Oct 2002 16:22:11 -0700 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 16:22:10 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 19 Oct 2002 16:22:10 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Sat, 19 Oct 2002 16:22:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Date: Sat, 19 Oct 2002 16:22:10 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10738433C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Thread-Index: AcJ2Cy+0vlSptp5qRk+aFuGl9qxriwBCnOkgACutvlA= From: "Dave Thaler" To: X-OriginalArrivalTime: 19 Oct 2002 23:22:10.0655 (UTC) FILETIME=[5960EEF0:01C277C6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9JNM929023264 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just trying to catch up on email... a few comments below. I've already seen other people answering most questions in the same way I would, so (as another individual who supports this draft going forward) I'll concentrate on responding to other points. Margaret writes: > I think that it should be required (a MUST) that nodes that > implement this specification provide a method to override the > default values manually. I support this suggestion. (Others might suggest removing the word "manually".) Pekka writes: > Options a) - c) should be sufficient to describe how the routing system > will get the information. Perhaps it should be reworded to be something > like: > d) Developing an "announcement" protocol [...] > [...]. However, the three first mechanisms should > cover the necessary techniques sufficiently for most cases. I would support this suggestion as well. Jonne writes (responding to Pekka): > I do not really see what harm would three addresses do. You may have > networks that would have only one DNS server (small business or a home > user with for a reason or another his own DNS server). However, in cases > like ISPs or bigger businesses there may be multiple DNS servers > configure. I believe this is the case even now. Correct. Three was chosen based on common practice in the many places in the industry. While it's true that if the first one fails, that it's unlikely the second one will succeed (due to there really being no DNS server at all), using multiple addresses is important so that when ones do exist, the host can fail over to a second server more quickly than routing converges. More on this below. Rob writes: > My main objection was and remains that this mechanism, if used, moves > state away from the endpoints and into the network in a way that cripples > the resolver's ability to keep track of which of the name servers it is > using are performing properly, since the binding between any particular > well-known-address and the name server behind it might change at any time > and since there is no mechanism by which the resolver can find out that > such a change has taken place. The above objection appears to be against anycast addresses. This draft is about *unicast* addresses, not anycast addresses. Hence, no such change can take place. The use of 3 unicast addresses is specifically to enable the resolver to keep track of which of the name servers it is using are performing properly. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 16:34:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNYG29023532; Sat, 19 Oct 2002 16:34:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JNYGeM023531; Sat, 19 Oct 2002 16:34:16 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNYD29023524 for ; Sat, 19 Oct 2002 16:34:13 -0700 (PDT) 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 g9JNYLMq018666 for ; Sat, 19 Oct 2002 16:34:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16592 for ; Sat, 19 Oct 2002 16:34:15 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9JNXuV16884; Sun, 20 Oct 2002 02:33:57 +0300 Date: Sun, 20 Oct 2002 02:33:56 +0300 (EEST) From: Pekka Savola To: "Alper E. YEGIN" cc: "Nick 'Sharkey' Moore" , Subject: Re: Optimistic DAD draft ... In-Reply-To: <021401c27706$5842b0f0$696015ac@AlperVAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Oct 2002, Alper E. YEGIN wrote: [...] > > Optimistic DAD is a useful optimization because DAD is far more > > likely to succeed than fail, by a factor of at least 10,000,000,000 > > to one[SOTO]. This makes it worth a little disruption in the failure > > case to provide faster handovers in the successful case, as long as > > the disruption is recoverable. > > > > ==> this is totally, and completely wrong. [SOTO] only provide analysis > > in *some* cases, in particular autoconfigured vs privacy addresses. For > > manually assigned addresses, I believe the ratio is closer to 1:10 or > > 1:100 (unmeasurable, of course). > > I must be missing something.. How come this probability is so high? It's due to the fact how manually assigning works. There are two factors: 1) IID assignment ("which address to use") 2) configuration ("avoiding typos") It is natural that people doing manual configuration will try to prefer IID's like ::1, ::2, ::53, ::x etc. and there are much more likely to be conflicts there; also one should never underestimate the power of fat fingers :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 19 16:50:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNok29023652; Sat, 19 Oct 2002 16:50:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9JNokhF023651; Sat, 19 Oct 2002 16:50:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9JNoh29023644 for ; Sat, 19 Oct 2002 16:50:43 -0700 (PDT) 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 g9JNopPG011042 for ; Sat, 19 Oct 2002 16:50:51 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10743 for ; Sat, 19 Oct 2002 17:50:45 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9JNoi0K173646 for ; Sat, 19 Oct 2002 19:50:45 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9JNofcl027010 for ; Sat, 19 Oct 2002 19:50:42 -0400 Importance: Normal Sensitivity: Subject: RE: IPv6 MIB Design team - new RFC2012 draft To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Kristine Adamson Date: Sat, 19 Oct 2002 19:50:42 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/19/2002 17:50:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On October 19, 2002 Dave Thaler wrote: >> From: Kristine Adamson [mailto:adamson@us.ibm.com] >> >> I have a question about the tcpListenerEstablished MIB object in the >>June >> 2002 version of the new RFC2012 MIB draft. Is this counter only >>supposed >> to represent the number of connections that have transitioned to the >> established state for a Listener, or the number of connections in >> established state that have also been accepted for a Listener? >I'm not sure whether I understand your question. Are you asking >whether it counts how many have ever transitioned to established >vs the number currently in established state? >If so, the answer is the former, since this is a Counter and not a >Gauge. Dave, In our implementation, a connection can transition to the established state for a particular Listener without having yet been accepted by the Listener. So my question is, does this MIB object count allthose connections that have transitioned to the established state for a Listener or, those connections in established state that have also been accepted by that Listener. 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 Sat Oct 19 20:37:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3b229024017; Sat, 19 Oct 2002 20:37:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9K3b2tF024016; Sat, 19 Oct 2002 20:37:02 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3ax29024009 for ; Sat, 19 Oct 2002 20:36:59 -0700 (PDT) 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 g9K3b7Mq013732 for ; Sat, 19 Oct 2002 20:37:07 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24841 for ; Sat, 19 Oct 2002 21:37:02 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6CF1A2FB6; Sat, 19 Oct 2002 23:37:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 19 Oct 2002 23:37:01 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPV6_V6ONLY and a possible generic alternative X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 19 Oct 2002 23:37:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE95DD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPV6_V6ONLY and a possible generic alternative Thread-Index: AcJ3sNI0W8z5QoUfS8mJyDiCdMwHDgAOKuqg From: "Bound, Jim" To: "Kyle C Quest" , X-OriginalArrivalTime: 20 Oct 2002 03:37:01.0200 (UTC) FILETIME=[F340F100:01C277E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9K3ax29024010 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This would not change what the default is today which is NOT IPV6_V6ONLY per the IEEE spec. If we want to add redefinition of options or structures for the base API I suggest that it be done in a new draft to the current draft of the Base API. We should move the latest rev to Info RFC and folks can start building addendum INFO RFCs. To change the base API which is now widely implemented is really out of the hands of the IETF per se. But addendums can be proposed to new work in IEEE. Mail to Bob Hinden exists to wrap this draft up and move on. Regards, /jim > -----Original Message----- > From: Kyle C Quest [mailto:kquest@unital.com] > Sent: Saturday, October 19, 2002 4:36 PM > To: ipng@sunroof.eng.sun.com > Subject: IPV6_V6ONLY and a possible generic alternative > > > The rfc2553bis draft introduces the IPV6_V6ONLY socket option > to let applications limit the use of an ipv6 socket to ipv6 > communication only. I think a better(more generic) solution > would be a generic socket option which says "my family only". > There could be "SO_ONEFAMILY" or similar generic socket > option to do that. The idea is that if we have a socket and > we want to restrict it to IPv6 or IPv4 (or some future IPvX) > we'd have a way to do that. > > I don't know if this idea has been already discussed here... > (I checked only the last couple of months). I'd like to know > what people think about it. > > Thank you, > > Kyle C Quest > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 19 20:37:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3bs29024034; Sat, 19 Oct 2002 20:37:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9K3bsnn024033; Sat, 19 Oct 2002 20:37:54 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3bo29024026 for ; Sat, 19 Oct 2002 20:37:50 -0700 (PDT) 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 g9K3bxMq013785 for ; Sat, 19 Oct 2002 20:37:59 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16107 for ; Sat, 19 Oct 2002 21:37:53 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3F355591C; Sat, 19 Oct 2002 23:37:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 19 Oct 2002 23:37:53 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPV6_V6ONLY and a possible generic alternative X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 19 Oct 2002 23:37:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE95DE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPV6_V6ONLY and a possible generic alternative Thread-Index: AcJ3sx3/ceQq5e+jTJCOoP0Z29MtfQANuX/Q From: "Bound, Jim" To: "Markku Savela" , Cc: X-OriginalArrivalTime: 20 Oct 2002 03:37:53.0043 (UTC) FILETIME=[12278E30:01C277EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9K3bp29024027 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I happen to agree with you. /jim > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Saturday, October 19, 2002 5:00 PM > To: kquest@unital.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPV6_V6ONLY and a possible generic alternative > > > > > From: "Kyle C Quest" > > > > The rfc2553bis draft introduces the IPV6_V6ONLY socket > option to let > > applications limit the use of an ipv6 socket to ipv6 communication > > only. I think a better(more generic) solution would be a generic > > socket option which says "my family only". There could be > > "SO_ONEFAMILY" or similar generic socket option to do that. > The idea > > is that if we have a socket and we want to restrict it to > IPv6 or IPv4 > > (or some future IPvX) we'd have a way to do that. > > This is wrong direction to go. MOST applications should never > care whether the communication is over IPv6 or IPv4 (or > whatever IPvX). > > If a new IPv6 application is written, it should work the same > with IPv4 and IPv6. If it does not, then I would consider > application (and API) broken. > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 19 20:39:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3de29024053; Sat, 19 Oct 2002 20:39:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9K3ddR4024052; Sat, 19 Oct 2002 20:39:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9K3da29024045 for ; Sat, 19 Oct 2002 20:39:36 -0700 (PDT) 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 g9K3diPG000171 for ; Sat, 19 Oct 2002 20:39:44 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23380 for ; Sat, 19 Oct 2002 21:39:39 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9F9B18C4; Sat, 19 Oct 2002 23:39:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 19 Oct 2002 23:39:38 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPV6_V6ONLY and a possible generic alternative X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 19 Oct 2002 23:39:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE95DF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPV6_V6ONLY and a possible generic alternative Thread-Index: AcJ3tmdlxyahW50wQqKyFxL84c9FTQAM6+sQ From: "Bound, Jim" To: "Kyle C Quest" , "Markku Savela" Cc: X-OriginalArrivalTime: 20 Oct 2002 03:39:38.0475 (UTC) FILETIME=[50FF33B0:01C277EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9K3da29024046 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The reason we have an IPV6_V6ONLY option is because some implementors would like to only run IPv6 packets over the socket and not permit IPv4_MAPPED. This was to give those implementors that capability. But the default is IPv4_MAPPED and IPv6. /jim > -----Original Message----- > From: Kyle C Quest [mailto:kquest@unital.com] > Sent: Saturday, October 19, 2002 5:16 PM > To: Markku Savela > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPV6_V6ONLY and a possible generic alternative > > > > ----- Original Message ----- > From: "Markku Savela" > To: > Cc: > Sent: Saturday, October 19, 2002 4:59 PM > Subject: Re: IPV6_V6ONLY and a possible generic alternative > > > > > > > From: "Kyle C Quest" > > > > > > The rfc2553bis draft introduces the IPV6_V6ONLY socket > option to let > > > applications limit the use of an ipv6 socket to ipv6 > communication > > > only. I think a better(more generic) solution > would be > > > a generic socket option which says "my family only". > > > There could be "SO_ONEFAMILY" or similar generic socket > option to do > that. > > > The idea is that if we have a socket > > > and we want to restrict it to IPv6 or IPv4 (or some future IPvX) > > > we'd > have a > > > way to do that. > > > > This is wrong direction to go. MOST applications should never care > > whether the communication is over IPv6 or IPv4 (or whatever IPvX). > > > > If a new IPv6 application is written, it should work the same with > > IPv4 and IPv6. If it does not, then I would consider > application (and > > API) broken. > > > > You bring up a good point... but why then rfc2553bis draft > defines IPV6_V6ONLY option? > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 20 11:09:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KI9t29026052; Sun, 20 Oct 2002 11:09:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9KI9sML026051; Sun, 20 Oct 2002 11:09:54 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KI9p29026038 for ; Sun, 20 Oct 2002 11:09:51 -0700 (PDT) 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 g9KI9xMq025565 for ; Sun, 20 Oct 2002 11:09:59 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26460 for ; Sun, 20 Oct 2002 12:09:53 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 94AD818E6 for ; Sun, 20 Oct 2002 14:09:50 -0400 (EDT) Date: Sun, 20 Oct 2002 14:09:50 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <3DAC9DC2.8020208@sun.com> References: <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> <20021012035945.39EAC18FA@thrintun.hactrn.net> <3DAC9DC2.8020208@sun.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021020180950.94AD818E6@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Tue, 15 Oct 2002 15:59:14 -0700, alain durand wrote: > > But isn't this already the case today, at least with some root servers > operating with an anycast address? See RFC3258. And if you read that RFC you will see that it calls for great care in making sure that the zone content is identical at every server. In the case of root name servers, and assuming that we do get DNSSEC deployed, that risk may be justified as a way of getting past the limit on the number of root name servers imposed by UDP packet length constraints. I don't see an equivilant case here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 20 11:18:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KII429026144; Sun, 20 Oct 2002 11:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9KII4Ec026143; Sun, 20 Oct 2002 11:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KII129026136 for ; Sun, 20 Oct 2002 11:18:01 -0700 (PDT) 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 g9KII9PG001280 for ; Sun, 20 Oct 2002 11:18:09 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28590 for ; Sun, 20 Oct 2002 12:18:03 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 33DAE18DA for ; Sun, 20 Oct 2002 14:18:02 -0400 (EDT) Date: Sun, 20 Oct 2002 14:18:02 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0B86@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F0B86@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021020181802.33DAE18DA@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Thu, 17 Oct 2002 19:03:48 +0200, Hesham Soliman wrote: > > Are you assuming that more than one server will be configured with > the same well-known site-local address? Because I don't think this > is necessary, now that we have 3 different addresses. The binding > betweem the well-known address and the name server need not change. Since the alleged purpose of this mechanism is to avoid using any kind of real discovery protocol, and given the discussion of route injection in the draft, I am assuming that the recovery mechanisms in case of a server failure may include fiddling with the routing 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 Sun Oct 20 11:43:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KIh729026343; Sun, 20 Oct 2002 11:43:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9KIh60b026342; Sun, 20 Oct 2002 11:43:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KIh329026335 for ; Sun, 20 Oct 2002 11:43:03 -0700 (PDT) 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 g9KIhBPG003740 for ; Sun, 20 Oct 2002 11:43:11 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01060 for ; Sun, 20 Oct 2002 11:43:06 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE1EF18DA for ; Sun, 20 Oct 2002 14:43:04 -0400 (EDT) Date: Sun, 20 Oct 2002 14:43:04 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10738433C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC10738433C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021020184305.EE1EF18DA@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Sat, 19 Oct 2002 16:22:10 -0700, Dave Thaler wrote: > > Rob writes: > > My main objection was and remains that this mechanism, if used, > > moves state away from the endpoints and into the network in a way > > that cripples the resolver's ability to keep track of which of the > > name servers it is using are performing properly, since the > > binding between any particular well-known-address and the name > > server behind it might change at any time and since there is no > > mechanism by which the resolver can find out that such a change > > has taken place. > > The above objection appears to be against anycast addresses. Sorry, wrong, and I think we had this discussion already. > This draft is about *unicast* addresses, not anycast addresses. > Hence, no such change can take place. The use of 3 unicast > addresses is specifically to enable the resolver to keep track of > which of the name servers it is using are performing properly. And what happens if all three servers fail? Bringing up a new name server is not hard, but if I understand you correctly it won't help to bring up a new server because there's no way to switch over. Perhaps the IPv6 WG should leave DNS operational issues to the WG that's chartered to deal with them and instead spend IPv6 WG time on issues that have something to do with IPv6 (eg, figuring out how and if address scopes other than global and link-local are going to work)? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 20 15:30:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KMU729027120; Sun, 20 Oct 2002 15:30:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9KMU6vt027119; Sun, 20 Oct 2002 15:30:06 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9KMU329027112 for ; Sun, 20 Oct 2002 15:30:03 -0700 (PDT) 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 g9KMUAMq025830 for ; Sun, 20 Oct 2002 15:30:10 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24997 for ; Sun, 20 Oct 2002 16:30:04 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9KMU0KV028891; Mon, 21 Oct 2002 00:30:01 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 21 Oct 2002 00:30:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BA2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rob Austein'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addres ses for DNS resolver" Date: Mon, 21 Oct 2002 00:30:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At Thu, 17 Oct 2002 19:03:48 +0200, Hesham Soliman wrote: > > > > Are you assuming that more than one server will be configured with > > the same well-known site-local address? Because I don't think this > > is necessary, now that we have 3 different addresses. The binding > > betweem the well-known address and the name server need > not change. > > Since the alleged purpose of this mechanism is to avoid > using any kind > of real discovery protocol, and given the discussion of route > injection in the draft, I am assuming that the recovery > mechanisms in > case of a server failure may include fiddling with the > routing system. => I didn't get that impression. You mean if 3 servers fail at the same time ? I don't have a problem with assuming that the DNS discovery mechanism in this draft will fail if all 3 servers fail at the same time. Perhaps we can can add that to the draft. Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 03:46:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LAka29028619; Mon, 21 Oct 2002 03:46:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LAka8A028618; Mon, 21 Oct 2002 03:46:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LAkX29028611 for ; Mon, 21 Oct 2002 03:46:33 -0700 (PDT) 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 g9LAkePG020663 for ; Mon, 21 Oct 2002 03:46:40 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12948 for ; Mon, 21 Oct 2002 04:46:30 -0600 (MDT) 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 g9LAjkR23226; Mon, 21 Oct 2002 17:45:48 +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 g9LAjTr19163; Mon, 21 Oct 2002 17:45:33 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> References: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 17:45:29 +0700 Message-ID: <19161.1035197129@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Oct 2002 13:59:59 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20021016131237.02b34290@mail.windriver.com> | I think that it should be required (a MUST) that nodes that | implement this specification provide a method to override the | default values manually. If the doc is to remain at all, then yes, and as Brian hinted, "manually" is not important there. | The document should also specify whether the default DNS addresses | will or won't be considered part of the DNS server list when DNS | server addresses are configured via other means. For example, if | a host receives a single DNS server address via DHCP, will it | fall-back to using these well-known addresses if the DNS server | at the DCHP-configured address fails to respond? This all boils down to what is "last resort" which the doc doesn't really go into. I'm not absolutely convinced this is crucial, that is, that it doesn't necessarily matter if everyone does this the same way or not. What's clearly in issue here is how a new out of the box IPv6 node finds some back end resolver to handle its DNS queries, as without that, it is useless. After having found some way to make DNS queries, the question is really no longer important - if we get a list of DNS resolvers via DHCPv6 (say) and they're used, then the node is now operable. If those servers all go away/fail (and DHCPv6 hasn't, yet anyway, told us of new ones) then whether the node falls back to trying the well known addresses or not, is really just a question of user desire. Some users will just see packets being sent to nowhere, and increased timeouts while the app waits for the reply that will never come. They won't want the well known addresses used. Others would see the resolver giving up after its DHCPv6 address(es) have failed, and wonder why the node didn't just go on and try the well known addresses which have been carefully set up to provide the service. Those people will want the well known addresses retained. (If it really was DHCPv6 in that case then one could argue the DHCP server should have just included the well known addresses, but the "normal" back end resolver may have been learned via some other mechanism which cannot as easily just supply many addresses that way). | Listing anything as a "last resort" is problematic, because there | may be something that comes along later that should only be | used if this fails. I think this is partly a lack of defining "last resort of what". That is, I didn't think it was really intended to be "last resort of doing a name resolution" but "last resort of configuring addresses of back end resolvers that could be used to do name resolution". That is, this "last resort" is used at boot time only, when some initial configuration must be found. Or that's my impression of what it means. But it isn't very precise. | Instead, I would like to see this document | explicitly define how this mechanism does/doesn't interoperate | with other mechanisms (DHCP, SLP, manual configuration). That would be a reasonable idea. | In my opinion, this section points out one major weakness with | this approach. We _still_ need some way to configure the location | of DNS servers in the network... Yes. This scheme isn't really all that useful. | Today, we do that on hosts (often | using DHCP to provide the information, effectively moving the | configuration to the DHCP server). This draft proposes moving | that knowledge off of hosts and DHCP servers, and into the routing | system, but it doesn't actually specify how the routing system | will get the information. I don't think that's a serious problem either. Clearly something needs to be configured somewhere (unless the model is that every node is to be its own back end resolver, and will come pre-set with the root server addresses as a place to start - and I certainly hope that's never what happens). At the very least, some node needs to be configured as the back end (recursive) resolver. A little extra config to inform routing where that node lives isn't too much to expect really. It's still config on the order of the number of DNS back end resolvers (1, 2, or 3 or so), not of the order of the number of nodes connected to the network. The truly big problem with this draft is that it is usurping address assignments that have already been made elsewhere (I'll reply to a different message and make that point - once more). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 03:54:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LAsR29028682; Mon, 21 Oct 2002 03:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LAsQxx028681; Mon, 21 Oct 2002 03:54:26 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LAsN29028674 for ; Mon, 21 Oct 2002 03:54:23 -0700 (PDT) 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 g9LAsVMq026640 for ; Mon, 21 Oct 2002 03:54:31 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10312 for ; Mon, 21 Oct 2002 03:54:20 -0700 (PDT) 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 g9LAreR27044; Mon, 21 Oct 2002 17:53:40 +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 g9LArSr19189; Mon, 21 Oct 2002 17:53:28 +0700 (ICT) From: Robert Elz To: Derek Fawcus cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <20021017014040.B8106@edi-view1.cisco.com> References: <20021017014040.B8106@edi-view1.cisco.com> <4.3.2.7.2.20021011140953.02dc3bb0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 17:53:28 +0700 Message-ID: <19187.1035197608@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Oct 2002 01:40:40 +0100 From: Derek Fawcus Message-ID: <20021017014040.B8106@edi-view1.cisco.com> | I think this draft is a poor idea, and that if people want an | autoconfig mechanism, then something along the lines of | draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible. As a solution for DNS back end resolver discovery, that one is just fine. Its problem is that it doesn't scale, at all, to other things that also need to be discovered (we're also going to eventually need NTP servers, and the whole host of other things that DHCP is able to provide - or many of them anyway). Adding a new RA option for every one of those would eventually mean requiring jumbograms to hold RA packets (perhaps a slight exaggeration, but you get the point). But perhaps DNS is just such a fundamental service, that it can be treated as the one special case worth doing this way. | Mind one would still have to configure the router to generate the | above option in a RA, but then something would always have to be | configured somewhere. Yes, that isn't an issue to bother with (just as having to configure the routing system isn't the issue to worry about with the well known address "solution"). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 04:00:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB0829028798; Mon, 21 Oct 2002 04:00:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LB08aN028797; Mon, 21 Oct 2002 04:00:08 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB0529028790 for ; Mon, 21 Oct 2002 04:00:05 -0700 (PDT) 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 g9LB09Mq027198 for ; Mon, 21 Oct 2002 04:00:10 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19370 for ; Mon, 21 Oct 2002 04:59:59 -0600 (MDT) 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 g9LAxGR29481; Mon, 21 Oct 2002 17:59:16 +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 g9LAx2r19203; Mon, 21 Oct 2002 17:59:04 +0700 (ICT) From: Robert Elz To: Jonne.Soininen@nokia.com cc: dfawcus@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDAFE@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDEEBDAFE@mvebe001.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 17:59:02 +0700 Message-ID: <19201.1035197942@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Oct 2002 18:49:10 -0700 From: Jonne.Soininen@nokia.com Message-ID: <4D7B558499107545BB45044C63822DDEEBDAFE@mvebe001.americas.nokia.com> | I believe it is easy to miss the main point: We currently do not have | any mechanisms to configure a IPv6 host with the DNS resolver/server | address - except of course by manual configuration. I am sure that if | we wait a few years more, and keep working on this issue open we will | find a better or at least more politically correct solution. The problem | is that it does not solve our problem now. This is the "we need a solution today, it doesn't matter if it is a crappy solution, we have to have something so we can pretend we have done all of the work" argument. Some of us are not missing this at all... | The currently proposed DNS discovery solution is simple, true. | it does not break anything, Not true. It breaks my subnet assignment plan. I have already allocated SLA FFFF to use for P2P links. Now, after that's already out there and in use the WG is proposing to tell me to renumber things: gif0: flags=8051 mtu 1280 tunnel inet 128.250.1.21 --> 128.250.1.130 inet6 3ffe:8001:2:ffff::101:2 -> :: prefixlen 112 (this one happens not to have a SL address, but obviously we want our SL addr subnet numbers to be 1::1 with the globals). We should never be attempting to define the internals of anyone's address space usage. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 04:03:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB3C29028842; Mon, 21 Oct 2002 04:03:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LB3Cxg028841; Mon, 21 Oct 2002 04:03:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB3929028834 for ; Mon, 21 Oct 2002 04:03:09 -0700 (PDT) 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 g9LB3GPG022635 for ; Mon, 21 Oct 2002 04:03:16 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03585 for ; Mon, 21 Oct 2002 05:03:07 -0600 (MDT) 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 g9LB2LR00696; Mon, 21 Oct 2002 18:02:21 +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 g9LB20r19222; Mon, 21 Oct 2002 18:02:02 +0700 (ICT) From: Robert Elz To: "Richard Draves" cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 18:02:00 +0700 Message-ID: <19220.1035198120@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Oct 2002 11:12:09 -0700 From: "Richard Draves" Message-ID: | I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is | that site-locals are put in the DNS and it specifies a way for a node to | filter out the site-locals when they shouldn't be used). No, that's a hopeless idea, and I thought had already been discarded (the draft expired almost a year ago and hasn't been replaced). There are just too many failure modes for that one to have any chance at all. Aside from as used in isolated sites, SL addresses have no place in the DNS at all, ever. There are better ways to work out when and how to use SL addresses (some of which might even not engender Keith's wrath). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 04:05:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB5X29028883; Mon, 21 Oct 2002 04:05:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LB5Wr5028882; Mon, 21 Oct 2002 04:05:32 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB5T29028875 for ; Mon, 21 Oct 2002 04:05:29 -0700 (PDT) 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 g9LB5bMq028097 for ; Mon, 21 Oct 2002 04:05:37 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15155 for ; Mon, 21 Oct 2002 04:05:26 -0700 (PDT) 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 g9LB4dR01579; Mon, 21 Oct 2002 18:04:39 +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 g9LB4Lr19234; Mon, 21 Oct 2002 18:04:22 +0700 (ICT) From: Robert Elz To: Keith Moore cc: "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-Reply-To: <200210180049.g9I0nR006942@astro.cs.utk.edu> References: <200210180049.g9I0nR006942@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 18:04:20 +0700 Message-ID: <19232.1035198260@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 17 Oct 2002 20:49:27 -0400 From: Keith Moore Message-ID: <200210180049.g9I0nR006942@astro.cs.utk.edu> | forcing apps to deal with scopes at all is a serious problem. This is one view. Another is that an address is just a number, without some kind of scope to define its use, it is meaningless. Even "global" needs something to say which globe is being considered. It can be argued that all apps should always deal with address scoping and always should have. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 04:07:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB7b29028939; Mon, 21 Oct 2002 04:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LB7aLN028938; Mon, 21 Oct 2002 04:07:36 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LB7X29028931 for ; Mon, 21 Oct 2002 04:07:33 -0700 (PDT) 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 g9LB7fMq028377 for ; Mon, 21 Oct 2002 04:07:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08024 for ; Mon, 21 Oct 2002 04:07:32 -0700 (PDT) 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 g9LB6pR02089; Mon, 21 Oct 2002 18:06:51 +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 g9LB6Ur19271; Mon, 21 Oct 2002 18:06:39 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" In-Reply-To: <4.3.2.7.2.20021016094809.02a370c8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20021016094809.02a370c8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 18:06:30 +0700 Message-ID: <19269.1035198390@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that draft pretty much covers the issue it should cover in just about the right amount of detail. Ship it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 04:30:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LBUT29029198; Mon, 21 Oct 2002 04:30:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LBUTXj029197; Mon, 21 Oct 2002 04:30:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LBUP29029190 for ; Mon, 21 Oct 2002 04:30:25 -0700 (PDT) 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 g9LBUXMq001198 for ; Mon, 21 Oct 2002 04:30:33 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17038 for ; Mon, 21 Oct 2002 05:30:27 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA00573; Mon, 21 Oct 2002 14:28:26 +0300 Date: Mon, 21 Oct 2002 14:28:26 +0300 Message-Id: <200210211128.OAA00573@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ipng@sunroof.eng.sun.com In-reply-to: <19220.1035198120@munnari.OZ.AU> (message from Robert Elz on Mon, 21 Oct 2002 18:02:00 +0700) Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt References: <19220.1035198120@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > > Aside from as used in isolated sites, SL addresses have no place in the DNS > at all, ever. Unless we introduce a new model for name resolution, an extension of the current one. I would call it "scoped name resolution". It would have following properties - each name service is associated with a scope level - the service can be unicast or multilcast based - nodes need to have policy, which tells in which order the services are looked (hostfile, highest scope first or some other order). All current DNS servers are unicast based Global Scope (even if the address were site or link local). The proposed link local name resolution (LLNMR), is at link local scope and uses multicast. In such model, one can imagine setting up a name resolution at site scope, either as unicast server or based on multicast (using almost same logic as LLMNR). In theory, at each scope level, one could use either unicast or multicast approach, but of course, at global level multicast surely wont be feasible due to scaling problems... The scope level of the unicast server must be configured somehow, as it cannot be deduced from the address of the server (you can have global name server on the link using link local address, or you could have a linklocal scope unicast server -- alternative to LLMNR). At least for IPv6, the scope of the name service for multicast based resolutions can be deduced from the multicast 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 Oct 21 05:04:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC4E29029485; Mon, 21 Oct 2002 05:04:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LC4EtX029484; Mon, 21 Oct 2002 05:04:14 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC4B29029477 for ; Mon, 21 Oct 2002 05:04:11 -0700 (PDT) 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 g9LC4IMq004991 for ; Mon, 21 Oct 2002 05:04:18 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03166 for ; Mon, 21 Oct 2002 05:04:13 -0700 (PDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 14:04:12 +0200 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.6249.0 Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Date: Mon, 21 Oct 2002 14:04:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJ48f+i3VU0FZKOSCKcDWE9Q8YNygABpIzQ From: "BELOEIL Luc FTRD/DMI/CAE" To: "Robert Elz" , "Derek Fawcus" Cc: X-OriginalArrivalTime: 21 Oct 2002 12:04:12.0554 (UTC) FILETIME=[F82ACEA0:01C278F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9LC4B29029478 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all > From : Robert Elz [mailto:kre@munnari.OZ.AU] > Date : Mon, 21 oct 2002 12:53 > > Date: Thu, 17 Oct 2002 01:40:40 +0100 > From: Derek Fawcus > > | I think this draft is a poor idea, and that if people want an > | autoconfig mechanism, then something along the lines of > | draft-beloeil-ipv6-dns-resolver-option-00.txt would be > nore sensible. > > As a solution for DNS back end resolver discovery, that one > is just fine. > > Its problem is that it doesn't scale, at all, to other things > that also ... > But perhaps DNS is just such a fundamental service, that it > can be treated > as the one special case worth doing this way. > Good question ! What do the working group think about that point ? 1- Is DNS service such as fundamental that a special specification should help an efficient way to "discover" or "know" how to join DNS recursive resolvers? That could mean that the way to discover other servers like NTP servers or any other servers associated to a specific service would not be so favoured. 2- DNS service is just a service, and thus should be treated as any service. I have to admit that I feel better with point 1. Indeed, one of you have argued that most of other services that need a server can be discovered by resolving the domain name of the server. Luc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 05:05:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC5K29029502; Mon, 21 Oct 2002 05:05:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LC5Je6029501; Mon, 21 Oct 2002 05:05:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC5G29029494 for ; Mon, 21 Oct 2002 05:05:16 -0700 (PDT) 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 g9LC5NPG029595 for ; Mon, 21 Oct 2002 05:05:24 -0700 (PDT) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA00916 for ; Mon, 21 Oct 2002 06:05:15 -0600 (MDT) Message-ID: <002c01c278fa$14c5ce20$5c28010a@feroz> From: "Mohammad Feroz" To: Subject: IPSec Implementaion. Date: Mon, 21 Oct 2002 17:34:59 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C27928.2DE329B0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C27928.2DE329B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ! Is it mandatory to implement Security Architecture for IPv6 for HOSTS? Thanks & Best Regards, - Feroz ********************************************************* Mohammed Feroz, Networking & Communication Group, Design & Development Centre, TATA Elxsi Limited, Bangalore Phone: +91-80-8410222=20 Fax: +91-80-8410219 ********************************************************* ------=_NextPart_000_0029_01C27928.2DE329B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello !
 
Is it mandatory to implement Security = Architecture=20 for IPv6 for HOSTS?
 
Thanks & Best Regards,
-=20 Feroz
 
*********************************************************=
Mohammed=20 Feroz,
Networking & Communication Group,
Design & = Development=20 Centre,
TATA Elxsi Limited, Bangalore
Phone: +91-80-8410222 =
Fax:=20 +91-80-8410219
*******************************************************= **
------=_NextPart_000_0029_01C27928.2DE329B0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 05:07:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC7H29029528; Mon, 21 Oct 2002 05:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LC7HnU029525; Mon, 21 Oct 2002 05:07:17 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LC7D29029514 for ; Mon, 21 Oct 2002 05:07:13 -0700 (PDT) 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 g9LC7LMq005258 for ; Mon, 21 Oct 2002 05:07:21 -0700 (PDT) Received: from webmail28.rediffmail.com (webmail28.rediffmail.com [203.199.83.38] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA22060 for ; Mon, 21 Oct 2002 06:07:13 -0600 (MDT) Received: (qmail 2728 invoked by uid 510); 21 Oct 2002 12:08:57 -0000 Date: 21 Oct 2002 12:08:57 -0000 Message-ID: <20021021120857.2727.qmail@webmail28.rediffmail.com> Received: from unknown (203.196.146.242) by rediffmail.com via HTTP; 21 oct 2002 12:08:56 -0000 MIME-Version: 1.0 From: "Ramakrishnan" Reply-To: "Ramakrishnan" To: ipng@sunroof.eng.sun.com Subject: Routing header processing Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In RFC-2460 heading 4.4 Routing Header, says how to process routing header in a NODE. processing of the routing header by a HOST is not clear if the segments-left field in the routing header is non-zero. What should a host do with such packets ? should it process the packet according to the RFC or reject the packet since host is not supposed to forward the packet. Regards, Ramakrishnan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 05:33:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCXW29029874; Mon, 21 Oct 2002 05:33:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LCXWnt029873; Mon, 21 Oct 2002 05:33:32 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCXT29029866 for ; Mon, 21 Oct 2002 05:33:29 -0700 (PDT) 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 g9LCXaMq008801 for ; Mon, 21 Oct 2002 05:33:36 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20969 for ; Mon, 21 Oct 2002 06:33:31 -0600 (MDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 14:33:30 +0200 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.6249.0 Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Date: Mon, 21 Oct 2002 14:33:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJ48D7fbiRcvARORFe03MyZ+LBMcgACcyiw From: "BELOEIL Luc FTRD/DMI/CAE" To: "Robert Elz" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 21 Oct 2002 12:33:30.0554 (UTC) FILETIME=[100451A0:01C278FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9LCXT29029867 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To my mind, this draft is a simple and efficient way to pre-configure one's network. Thus I'd prefer to consider it as a way to introduce a "by-default manual configuration" in my devices but not a hard coded solution that I could not change easily. I understand that 3G networks and small sheap devices would have full benefit of such a mechanism. But in other scenarii, that could introduce pb: - the draft impose to fixe 3 addresses in any network (one disagrees see below) - the draft impose to introduce those addresses in the routing system - the draft impose to use site-local address whereas sites and site borders are not clearly idendified / understood (?). Luc > From : Robert Elz [mailto:kre@munnari.OZ.AU] > Date : Mon, 21 oct 2002 12:45 > > The truly big problem with this draft is that it is usurping address > assignments that have already been made elsewhere (I'll reply to a > different message and make that point - once more). > > kre > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 05:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCb929029916; Mon, 21 Oct 2002 05:37:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LCb9bZ029915; Mon, 21 Oct 2002 05:37:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCb529029908 for ; Mon, 21 Oct 2002 05:37:05 -0700 (PDT) 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 g9LCbDPG003788 for ; Mon, 21 Oct 2002 05:37:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22591 for ; Mon, 21 Oct 2002 06:37:07 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9LCb1X06426; Mon, 21 Oct 2002 15:37:01 +0300 Date: Mon, 21 Oct 2002 15:37:01 +0300 (EEST) From: Pekka Savola To: Ramakrishnan cc: ipng@sunroof.eng.sun.com Subject: Re: Routing header processing In-Reply-To: <20021021120857.2727.qmail@webmail28.rediffmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 21 Oct 2002, Ramakrishnan wrote: > In RFC-2460 heading 4.4 Routing Header, says how to process > routing header in a NODE. processing of the routing header by a > HOST is not clear if the segments-left field in the routing header > is non-zero. > What should a host do with such packets ? should it process the > packet according to the RFC or reject the packet since host is not > supposed to forward the packet. > > Regards, > Ramakrishnan > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 05:37:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCb229029906; Mon, 21 Oct 2002 05:37:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LCb24c029905; Mon, 21 Oct 2002 05:37:02 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCaw29029898 for ; Mon, 21 Oct 2002 05:36:58 -0700 (PDT) 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 g9LCb6Mq009198 for ; Mon, 21 Oct 2002 05:37:06 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03363 for ; Mon, 21 Oct 2002 06:37:00 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9LCabu06421; Mon, 21 Oct 2002 15:36:37 +0300 Date: Mon, 21 Oct 2002 15:36:37 +0300 (EEST) From: Pekka Savola To: BELOEIL Luc FTRD/DMI/CAE cc: Robert Elz , Derek Fawcus , Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 21 Oct 2002, BELOEIL Luc FTRD/DMI/CAE wrote: > Good question ! What do the working group think about that point ? > > 1- Is DNS service such as fundamental that a special specification > should help an efficient way to "discover" or "know" how to join DNS > recursive resolvers? That could mean that the way to discover other > servers like NTP servers or any other servers associated to a specific > service would not be so favoured. > > 2- DNS service is just a service, and thus should be treated as any > service. > > I have to admit that I feel better with point 1. Indeed, one of you have > argued that most of other services that need a server can be discovered > by resolving the domain name of the server. I agree on point 1. Using DNS, we could specify very simple mechanisms for service discovery (note: those services, unlike to DNS, are not really required for all notes. Stuff like NTP should be on every node, of course, but world doesn't end if it isn't.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 05:39:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCdC29029952; Mon, 21 Oct 2002 05:39:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LCdBdP029951; Mon, 21 Oct 2002 05:39:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LCd729029944 for ; Mon, 21 Oct 2002 05:39:07 -0700 (PDT) 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 g9LCdFPG003974 for ; Mon, 21 Oct 2002 05:39:15 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29190 for ; Mon, 21 Oct 2002 05:39:09 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9LCd4Q06443; Mon, 21 Oct 2002 15:39:04 +0300 Date: Mon, 21 Oct 2002 15:39:04 +0300 (EEST) From: Pekka Savola To: Ramakrishnan cc: ipng@sunroof.eng.sun.com Subject: Re: Routing header processing 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 Sorry for the empty message, hit too many buttons. Have a look at (an expired draft): http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-hosts-00.txt This has not generated as much discussion as I hoped. On Mon, 21 Oct 2002, Pekka Savola wrote: > On 21 Oct 2002, Ramakrishnan wrote: > > In RFC-2460 heading 4.4 Routing Header, says how to process > > routing header in a NODE. processing of the routing header by a > > HOST is not clear if the segments-left field in the routing header > > is non-zero. > > What should a host do with such packets ? should it process the > > packet according to the RFC or reject the packet since host is not > > supposed to forward the packet. > > > > > > Regards, > > Ramakrishnan > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 07:27:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LERp29000404; Mon, 21 Oct 2002 07:27:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LERoZQ000403; Mon, 21 Oct 2002 07:27:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LERl29000396 for ; Mon, 21 Oct 2002 07:27:47 -0700 (PDT) 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 g9LERtMq029259 for ; Mon, 21 Oct 2002 07:27:55 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15733 for ; Mon, 21 Oct 2002 07:27:49 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 66CDB5BCE; Mon, 21 Oct 2002 10:27:49 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id F1347473; Mon, 21 Oct 2002 10:27:48 -0400 (EDT) Message-ID: <3DB40EE4.3060105@hp.com> Date: Mon, 21 Oct 2002 10:27:48 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... References: <20021015125759.B23137@dwerryhouse.com.au> <3DB04281.8090909@hp.com> <20021019112239.A12988@dwerryhouse.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick Nick 'Sharkey' Moore wrote: > On Fri, Oct 18, 2002 at 01:18:57PM -0400, Vladislav Yasevich wrote: > > > > Okay, I'll look into making this less ambiguous. The difficulty is > that the changes are relatively small compared to the main text > (eg, 2461/2462), and so I've tried to emphasize the changes rather > than providing the full rules and making people work out the > difference! If you would just quote the sentences or paragraphs you wish to modify, it will clear things up. > >> For the simple case, there is a very minor effect on the operation >> of non-optimistic nodes. An optimistic node will force the state >> of all REACHABLE entries to transition to STALE and may force NUD. >> This is a very minor effect, but it should be noted. > > > A NA with S=0,O=0 for a REACHABLE entry will have no effect on the > entry according to the Appendix C state machine, and these are the > only NAs which the ON will sent to All Nodes which Tentative. > Admittedly an NA with S=1,O=0 will reset a REACHABLE entry to STALE, > but why is the correspondent soliciting for a REACHABLE entry? > (Or have I missed something elsewhere?) Hmm. Here is a quote from rfc 2461, section 7.2.5: "If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, processing becomes quite a bit more complex. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache." It doesn't state anything about the the 'S' bit. > > Thanks for your feedback ... you've certainly given me lots to > think about on Monday! You are welcome. -vlad > > -----Nick > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 08:45:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LFjo29000975; Mon, 21 Oct 2002 08:45:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LFjohU000974; Mon, 21 Oct 2002 08:45:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LFjk29000967 for ; Mon, 21 Oct 2002 08:45:47 -0700 (PDT) Received: from localhost (d-mpk17-88-244.Eng.Sun.COM [129.146.88.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9LFjhL26743; Mon, 21 Oct 2002 17:45:44 +0200 (MEST) Date: Mon, 21 Oct 2002 17:42:52 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" To: Alain Durand Cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Those are two different things. dns-resolver discovery is to be used > to locate a DNS resolver/server in last resort when no other information > for finding this server is available. Reading the document I don't see a separate step where the DNS resolver/server is located. Instead I see that as a last resort DNS queries are sent to a well-known site-local unicast address. > LLMNR (at least to my understanding) is to be used > in last resort when the information had not been found in the DNS maps > (meaning you already have found a DNS server/resolver). As I understand the intent one goal is for LLMNR to work on a network consisting of just a few hosts, i.e. there might not be any router or DNS resolver. In that case a likely LLMNR usage end up being that when resolving host names as a last resort when DNS didn't return an answer, then use LLMNR. Thus I can't tell which of these last resorts should be the last one. > I thought that the IETF was in the business of specifying protocols, > not how people should implement them nor how people should > use them. > The best we can do here is to providing guidelines like > "use it only under those circumstances if you don't want to get hurt" I think that specifying protocols and folks implementing them is a bad idea unless the result is actually operationally useful. Thus ignoring operational issues as you seem to advocate doesn't make for quality IETF standards. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 09:07:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LG7s29001185; Mon, 21 Oct 2002 09:07:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LG7s80001184; Mon, 21 Oct 2002 09:07:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LG7o29001177 for ; Mon, 21 Oct 2002 09:07:51 -0700 (PDT) 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 g9LG7wPG009694 for ; Mon, 21 Oct 2002 09:07:58 -0700 (PDT) Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23447 for ; Mon, 21 Oct 2002 10:07:52 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id DF8EC34B for ; Mon, 21 Oct 2002 12:07:51 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id BAB131EC for ; Mon, 21 Oct 2002 16:07:50 +0000 (GMT) Date: Mon, 21 Oct 2002 12:07:50 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021021160750.BAB131EC@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 21 Oct 2002 15:36:37 +0300 (EEST), Pekka Savola wrote: > > Using DNS, we could specify very simple mechanisms for service discovery > (note: those services, unlike to DNS, are not really required for all > notes. Stuff like NTP should be on every node, of course, but world > doesn't end if it isn't.) See previous discussion of DNSSEC and (S)NTP. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 11:50:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LIot29002184; Mon, 21 Oct 2002 11:50:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LIotV5002183; Mon, 21 Oct 2002 11:50:55 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LIoq29002176 for ; Mon, 21 Oct 2002 11:50:52 -0700 (PDT) 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 g9LIoxMq011143 for ; Mon, 21 Oct 2002 11:50:59 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10039 for ; Mon, 21 Oct 2002 12:50:53 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9LIonM10120; Mon, 21 Oct 2002 21:50:50 +0300 Date: Mon, 21 Oct 2002 21:50:49 +0300 (EEST) From: Pekka Savola To: Rob Austein cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <20021021160750.BAB131EC@thangorodrim.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 21 Oct 2002, Rob Austein wrote: > At Mon, 21 Oct 2002 15:36:37 +0300 (EEST), Pekka Savola wrote: > > > > Using DNS, we could specify very simple mechanisms for service discovery > > (note: those services, unlike to DNS, are not really required for all > > notes. Stuff like NTP should be on every node, of course, but world > > doesn't end if it isn't.) > > See previous discussion of DNSSEC and (S)NTP. Can you elaborate, which discussion? I did a few searches in the mail archive but didn't find anything relevant. Note: NTP can be distributed through multicast (e.g. using the default address, I don't remember if specified for v6, probably not) and then time would be correct for DNSSEC. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 12:26:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LJQZ29002382; Mon, 21 Oct 2002 12:26:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LJQYW7002381; Mon, 21 Oct 2002 12:26:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LJQV29002374 for ; Mon, 21 Oct 2002 12:26:31 -0700 (PDT) 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 g9LJQcPG013673 for ; Mon, 21 Oct 2002 12:26:39 -0700 (PDT) Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03116 for ; Mon, 21 Oct 2002 13:26:32 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id E808D34B for ; Mon, 21 Oct 2002 15:26:31 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id A4C2A1EC for ; Mon, 21 Oct 2002 19:26:29 +0000 (GMT) Date: Mon, 21 Oct 2002 15:26:28 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <20020522191106.B9AE11C81@thrintun.hactrn.net> References: <20021021160750.BAB131EC@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: multipart/mixed; boundary="Multipart_Mon_Oct_21_15:26:28_2002-1" Message-Id: <20021021192629.A4C2A1EC@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Mon_Oct_21_15:26:28_2002-1 Content-Type: text/plain; charset=US-ASCII At Mon, 21 Oct 2002 21:50:49 +0300 (EEST), Pekka Savola wrote: > > Can you elaborate, which discussion? I did a few searches in the mail > archive but didn't find anything relevant. Postings dating back to March of this year, including the following. --Multipart_Mon_Oct_21_15:26:28_2002-1 Content-Type: message/rfc822 Date: Wed, 22 May 2002 15:11:06 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Threat model for DNS discovery (was: Stateless DNS discovery draft) Message-Id: <20020522191106.B9AE11C81@thrintun.hactrn.net> At Tue, 14 May 2002 20:19:32 -0400, Steve Bellovin wrote: > > >So how can we understand the threat model for DNS discovery? > > > That takes work... A good starting point would be Derek Atkins' and > Rob Austein's DNS threat analysis document > (draft-ietf-dnsext-dns-threats-01.txt) I haven't had a chance to > read it carefully in this context. Rob, I know you're on this > list... I replied to this over a week ago, but my reply never made it to the list (no doubt my message had the wrong RFC822 From: header). At any rate, as best as I can recall what I said last week, and with the understanding that I'm not claiming to understand all the issues here (far from it), this is just some preliminary thinking out loud (ok, on phospher): There's a fundamental question of whether one trusts the local network or not. I don't. Some do. Threat models for any discovery protocol depend heavily on where one stands on this point. Recursive mode (usually stub) resolvers without DNSSEC are walking targets: they're just throwing themselves on the mercy of some recursive mode name server and don't have much grounds for any kind of opinion on the results they get back. DNS Discovery probably doesn't change this model very much. Iterative mode resolvers without DNSSEC are also at risk (see the dns-threats draft), but the scenario is a bit different. In theory, an iterative mode resolver can try somewhat harder to get a valid answer, but without end-to-end data integrity protection the resolver is still in a pretty weak position. The main difference here as far as DNS Discovery is concered, though, is the bootstrap configuration data needed by an iterative mode resolver is (in practice) disjoint from the bootstrap configuration data needed by a recursive mode resolver. That is: while, in theory, an iterative mode resolver's "SBELT" (see RFC 1034) can be primed with some arbitrary list of name servers that the resolver turns to when it has no better idea of where to send a query, in practice SBELT is almost always set (via out of band means) to the IP addresses of the servers for the root zone. With DNSSEC, the picture is a bit different. DNSSEC provides an end-to-end data integrity check, so that resolvers are no longer just trusting name servers to return the right answer. But it's a bit more complex than that, with several subcases. A recursive mode (usually stub) resolver that uses the lame-oid "ask the recursive mode name server to do all that annoying DNSSEC junk" misfeature is not a lot better off than a recursive mode resolver without DNSSEC. Essential, there are now two separate trust mechanisms: the DNSSEC end-to-end data integrity check (which in this case does not go end-to-end), and whatever mechanism the resolver uses when it's talking to its chosen recusive mode name servers. The current least-bad mechanism for the latter mechanism is TSIG, but there's a nontrivial key distribution problem there. So either the recursive mode resolver needs some out-of-band knowledge of some kind of keying material that it can use to secure its conversations with its chosen recursive mode name servers, or the DNS discovery protocol has to supply the necessary keying material. As noted in the dns-threats draft, simply establishing a "secure" channel between the recursive mode resolver and the recursive mode name server isn't sufficient, because "secure" communication to a server that the resolver has no reason to trust is not particularly useful. Also note that hiding the DNS Discovery process from the resolver (which, in my opinion, is what the well-known-address proposal does) may make the (already bad) trust model here even worse: if the resolver doesn't know which name server is using a particular well-known IP address at the moment, it may have a harder time figuring out which key it use to talk to that name server. An iterative mode resolver is in fairly decent shape with DNSSEC, since it can perform the end-to-end integrity checks itself and thus no longer needs to trust any name server blindly, but there's a key distribution problem for this case too: the key for the root zone. Once again, either the resolver has to know that a priori, or the resolver needs some trustworthy way of acquiring that knowledge. There's a third weird case that has not yet received a lot of discussion: a recursive mode resolver that does its own validation of DNSSEC signatures. The basic idea here is that the DNSSEC integrity check is an end-to-end mechanism, while the mechanism by which DNS data is retrieved is essentially hop-by-hop (due to DNS caching). So it seems perfectly reasonable (to me, anyway) that an implementation might want to offload the process of fetching the data but still want to verify the integrity of the data. This case hasn't gotten a lot of attention to date, so the precise details of how one would go about this haven't been nailed down. I think it's possible (if somewhat annoying) to do this with DNSSEC as currently specified, which is why I haven't made a big issue out of it. For any case in which the resolver might be checking DNSSEC signatures, there's also a time discovery problem, because DNSSEC signature verification includes checking the expiration time. While it's probably safe to assume that any toaster capable of implementing DNS is capable of measuring elapsed time while the toaster is running, it's not safe to assume that every toasters has a clock that ticks while the toaster is turned off. So DNSSEC signature verification also adds a clock setting problem, which has its own set of trust issues. (S)NTP (with its authentication mechanism enabled) seems sufficient for this, but adds another key distribution problem. So: in all of the DNSSEC-using cases, there are key distribution problems of one kind or another. Big surprise. So part of the discovery question is to what extent one can or should use the discovery protocol to deal with the key distribution swamp. As far as I know, the discovery via well-known addresses proposal does not yet have any mechanism for dealing with this. It's not obvious to me where one would hang such a mechanism, but maybe I'm missing something. The "stateless DHCPv6" approach could, in theory, use DHCPv6's authentication mechanism, but as specified that mechanism doesn't look like an appropriate solution to this problem either. Then again, it might be possible to reuse the DHCPv6 authentication framework with different algorithms; that is, in this case, I can see where one might hang a mechanism, if we can come up with an appropriate mechanism. Ultimately, however, there's still the basic problem of to what extent the node trusts its local network, and what basis (eg, out-of-band keying) the node has for trusting any server it discovers if it doesn't trust the local network. --Rob --Multipart_Mon_Oct_21_15:26:28_2002-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 12:30:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LJUB29002405; Mon, 21 Oct 2002 12:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LJUB0p002404; Mon, 21 Oct 2002 12:30:11 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LJU729002397 for ; Mon, 21 Oct 2002 12:30:08 -0700 (PDT) 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 g9LJUFMq026733 for ; Mon, 21 Oct 2002 12:30:15 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10893 for ; Mon, 21 Oct 2002 13:30:09 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9LJU4Q1029103; Mon, 21 Oct 2002 21:30:04 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 21 Oct 2002 21:30:04 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BB2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , Ramakrishnan Cc: ipng@sunroof.eng.sun.com Subject: RE: Routing header processing Date: Mon, 21 Oct 2002 21:30:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Also see the recommendation in section 2.3 of: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-03.txt Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, October 21, 2002 2:39 PM > To: Ramakrishnan > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Routing header processing > > > Sorry for the empty message, hit too many buttons. > > Have a look at (an expired draft): > > http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-hosts-00.txt > > This has not generated as much discussion as I hoped. > > On Mon, 21 Oct 2002, Pekka Savola wrote: > > > On 21 Oct 2002, Ramakrishnan wrote: > > > In RFC-2460 heading 4.4 Routing Header, says how to process > > > routing header in a NODE. processing of the routing header by a > > > HOST is not clear if the segments-left field in the > routing header > > > is non-zero. > > > What should a host do with such packets ? should it process the > > > packet according to the RFC or reject the packet since > host is not > > > supposed to forward the packet. > > > > > > > > > > Regards, > > > Ramakrishnan > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 14:07:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LL7q29003033; Mon, 21 Oct 2002 14:07:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9LL7q7f003032; Mon, 21 Oct 2002 14:07:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9LL7m29003025 for ; Mon, 21 Oct 2002 14:07:48 -0700 (PDT) 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 g9LL7tPG011355 for ; Mon, 21 Oct 2002 14:07:56 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17265 for ; Mon, 21 Oct 2002 15:07:50 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9LL3w017400; Mon, 21 Oct 2002 17:03:58 -0400 (EDT) Message-Id: <200210212103.g9LL3w017400@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Mon, 21 Oct 2002 18:04:20 +0700.") <19232.1035198260@munnari.OZ.AU> Date: Mon, 21 Oct 2002 17:03:58 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | forcing apps to deal with scopes at all is a serious problem. > > This is one view. Another is that an address is just a number, > without some kind of scope to define its use, it is meaningless. > Even "global" needs something to say which globe is being considered. > > It can be argued that all apps should always deal with address scoping > and always should have. yes, it *can* be argued. OTOH, I haven't seen a convincing argument for this. because if you want apps to work reliably under these conditions then you are essentially asking hosts to do routing in the absence of routing information - so ideally the hosts should listen to routing updates and do their own route computation. which sort of implies that they're attached to the network for long periods of time rather than being nomadic. and if you designed the network to work in this way then you'd want your higher-layer protocols to be able to tolerate multiple destination addresses and/or changes to the destination address (with all of the security issues that this implies). so no, the argument doesn't stand up to scrutiny. at least, not in anything resembling the current Internet. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 19:21:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M2Lt29004001; Mon, 21 Oct 2002 19:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9M2LtJs004000; Mon, 21 Oct 2002 19:21:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M2Lp29003993 for ; Mon, 21 Oct 2002 19:21:51 -0700 (PDT) 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 g9M2LxPG028881 for ; Mon, 21 Oct 2002 19:21:59 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16069 for ; Mon, 21 Oct 2002 20:21:53 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B00272FD2; Mon, 21 Oct 2002 22:21:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 21 Oct 2002 22:21:52 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27971.C87C9B9B" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: IPSec Implementaion. Date: Mon, 21 Oct 2002 22:21:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9606@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec Implementaion. Thread-Index: AcJ4/EM/ea3caTXrSBGNSKqV4JRv2wAdWSbA From: "Bound, Jim" To: "Mohammad Feroz" , X-OriginalArrivalTime: 22 Oct 2002 02:21:52.0625 (UTC) FILETIME=[C8C27E10:01C27971] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C27971.C87C9B9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPsec is yes and the architecture. =20 /jim -----Original Message----- From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in]=20 Sent: Monday, October 21, 2002 8:05 AM To: ipng@sunroof.eng.sun.com Subject: IPSec Implementaion. =09 =09 Hello ! =20 Is it mandatory to implement Security Architecture for IPv6 for HOSTS? =20 Thanks & Best Regards, - Feroz =20 ********************************************************* Mohammed Feroz, Networking & Communication Group, Design & Development Centre, TATA Elxsi Limited, Bangalore Phone: +91-80-8410222=20 Fax: +91-80-8410219 ********************************************************* ------_=_NextPart_001_01C27971.C87C9B9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
IPsec=20 is yes and the architecture.
 
/jim
-----Original Message-----
From: = Mohammad Feroz=20 [mailto:feroz@tataelxsi.co.in]
Sent: Monday, October 21, = 2002 8:05=20 AM
To: ipng@sunroof.eng.sun.com
Subject: IPSec=20 Implementaion.

Hello !
 
Is it mandatory to implement Security=20 Architecture for IPv6 for HOSTS?
 
Thanks & Best Regards,
-=20 Feroz
 
*********************************************************=
Mohammed=20 Feroz,
Networking & Communication Group,
Design & = Development=20 Centre,
TATA Elxsi Limited, Bangalore
Phone: +91-80-8410222 =
Fax:=20 = +91-80-8410219
*******************************************************= **
=00 ------_=_NextPart_001_01C27971.C87C9B9B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 21 20:30:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M3UF29004197; Mon, 21 Oct 2002 20:30:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9M3UF5U004196; Mon, 21 Oct 2002 20:30:15 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M3UC29004189 for ; Mon, 21 Oct 2002 20:30:12 -0700 (PDT) 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 g9M3UKMq027264 for ; Mon, 21 Oct 2002 20:30:20 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07556 for ; Mon, 21 Oct 2002 21:30:13 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 7E868146C3; Tue, 22 Oct 2002 13:30:05 +1000 (EST) Date: Tue, 22 Oct 2002 13:30:04 +1000 From: "Nick 'Sharkey' Moore" To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021022133003.A32744@dwerryhouse.com.au> References: <20021015125759.B23137@dwerryhouse.com.au> <3DB04281.8090909@hp.com> <20021019112239.A12988@dwerryhouse.com.au> <3DB40EE4.3060105@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DB40EE4.3060105@hp.com>; from Vladislav.Yasevich@hp.com on Mon, Oct 21, 2002 at 10:27:48AM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Oct 21, 2002 at 10:27:48AM -0400, Vladislav Yasevich wrote: > [Nick Moore wrote:] > > > A NA with S=0,O=0 for a REACHABLE entry will have no effect on the > > entry according to the Appendix C state machine, and these are the > > only NAs which the ON will sent to All Nodes which Tentative. > > Admittedly an NA with S=1,O=0 will reset a REACHABLE entry to STALE, > > but why is the correspondent soliciting for a REACHABLE entry? > > (Or have I missed something elsewhere?) > > Hmm. Here is a quote from rfc 2461, section 7.2.5: > "If the target's Neighbor Cache entry is in any state other than > INCOMPLETE when the advertisement is received, processing becomes > quite a bit more complex. If the Override flag is clear and the > supplied link-layer address differs from that in the cache, then one > of two actions takes place: if the state of the entry is REACHABLE, > set it to STALE, but do not update the entry in any other way; > otherwise, the received advertisement should be ignored and MUST NOT > update the cache." Ah, I see what you mean. RFC 2461 contradicts itself then, since Appendix C states: | !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE | Override=1 address (if | different). | | !INCOMPLETE NA, Solicited=0, - unchanged | Override=0 | | !INCOMPLETE NA, Solicited=0, - unchanged | Override=1 | Same link-layer | address as cached. | | !INCOMPLETE NA, Solicited=0, Record link-layer STALE | Override=1 address. | Different link-layer | address than cached. Now, I understand that the main text would generally trump a mere Appendix, but the appendix rules seem to me to make more sense. My draft is based on the Appendix C rules so yes, I'd have to rethink a few things based on 7.2.5. Would one of the RFC2461 authors like to comment? -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 21 21:48:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M4ma29004381; Mon, 21 Oct 2002 21:48:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9M4maqF004380; Mon, 21 Oct 2002 21:48:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M4mW29004373 for ; Mon, 21 Oct 2002 21:48:32 -0700 (PDT) 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 g9M4mePG018695 for ; Mon, 21 Oct 2002 21:48:40 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14583 for ; Mon, 21 Oct 2002 21:48:34 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KNYWLR034A905H6V@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 22 Oct 2002 14:47:47 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4065912C002; Tue, 22 Oct 2002 14:47:46 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 43F7312C01F; Tue, 22 Oct 2002 14:47:37 +1000 (EST) Date: Tue, 22 Oct 2002 14:47:37 +1000 From: Greg Daley Subject: Re: Optimistic DAD draft ... To: "Alper E. YEGIN" Cc: Pekka Savola , "Nick 'Sharkey' Moore" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DB4D869.5020002@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=Windows-1252 Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <021401c27706$5842b0f0$696015ac@AlperVAIO> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alper, Sorry about the delayed response. Possibly unhelpful responses below... Alper E. YEGIN wrote: > Pekka, > > >> 2) I'm not sure if this is the right approach. Something better suited >>could be found, I believe, in adding functionality to first-hop routers' >>ND cache behaviour; a router could answer directly which could be >>interpreted like "don't use that address, I just recently saw it used here >>by another node.. but if you're really sure you want it, perform DAD as >>specified in RFC2461/2". > > > This is the approach I've been looking at. But there is a problem. > Nodes that implement the required ND extension can explicitely > inform the router about their IP addresses. Router can learn about > others (i.e., regular DAD hosts) via listening to multicast NSs for DAD. > No problems so far... > > But when a router starts with no state (a new one, or rebooting > after crash), it might never learn about regular nodes that > have already done DAD. > > So, unless this problem is solved, the applicability of this > solution is limited to networks where all nodes support the > required extensions.. Any ideas? With the mld-dad approach, the assumption is that all nodes will do MLD on subnet-local multicast addresses, and thus all nodes participate (to some extent) in the MLD reporting and query mechanisms defined by the RFC2710. Since MLD is a node requirement (good or bad) this is possible The issue with using ND based mechansims is that there's no generic query which all hosts (or a sufficient subset, as in MLD) will be guaranteed to respond to. In this case, the system cannot rebuild state from restart (nor necessarily converge to full state in a finite length of time, unless nodes can be prompted to send packets. Few (all or even many nodes) multicast packets in ND can cause a response, except for missing (lifetime 0?) router advertisements. In these cases, where the router lifetime is zero, or no multicast packets are received, a node will send an RS, although I don't know the effect on traffic from the nodes. (Nasty Hack I know). Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 22 01:18:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M8Iu29004901; Tue, 22 Oct 2002 01:18:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9M8IuQL004900; Tue, 22 Oct 2002 01:18:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9M8Iq29004893 for ; Tue, 22 Oct 2002 01:18:53 -0700 (PDT) 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 g9M8J0PG017348 for ; Tue, 22 Oct 2002 01:19:00 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08193 for ; Tue, 22 Oct 2002 01:18:49 -0700 (PDT) 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 g9M8I1R09697; Tue, 22 Oct 2002 15:18:03 +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 g9M8HDr25671; Tue, 22 Oct 2002 15:17:25 +0700 (ICT) From: Robert Elz To: Keith Moore cc: "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-Reply-To: <200210212103.g9LL3w017400@astro.cs.utk.edu> References: <200210212103.g9LL3w017400@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Oct 2002 15:17:13 +0700 Message-ID: <25669.1035274633@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 21 Oct 2002 17:03:58 -0400 From: Keith Moore Message-ID: <200210212103.g9LL3w017400@astro.cs.utk.edu> | because if you want apps to work reliably under these | conditions then you are essentially asking hosts to do routing in | the absence of routing information Sorry Keith, but what has routing got to do with anything? Address scoping is really just yet another level of naming, it is an extension to the address. Given any random address, with or without scoping information, there's always a possibility that the address won't work, for all kinds of reasons, so apps better be prepared to deal with that one way or another. That is, if you consider it important for an app to know which of several possible addresses (perhaps all "global" address) will work before using one, then you're right, there's a whole bunch of extra info that hosts would need to somehow discover first, but in practice, that isn't what anything does, "suck it and see" is the traditional approach - given multiple addresses, pick one (at random, though first come tends to be better) and see if it works, if so, then fine, if not, go on to the next. There's nothing about scoping that changes that in the slightest. Of course, the appropriate scope info has to be available with each address. The DNS has no way to return that info (nor do we have any global naming scheme for scopes that would allow it to), which is one reason why limited scope addresses should never appear in the DNS, except where the limited scope is (for other reasons) defined to be the universe (which is how we get by putting our current global addresses in the DNS - the globe of concern is "our globe" and all global addresses by definition refer to it). Other means of locating suitable limited scope addresses need to provide the scope information as a by product (which in many cases can be done by simply using the appropriate scope identifier from the interface over which the address was discovered). I know you're concerned about apps (protocols) which pass around addresses in the data (and consequently which aren't limited by the normal scope control measures). Where that happens the apps just need to take care not to pass an address to a node where it isn't known to be meaningful. Since that's hard to determine, a simpler rule that works, is simply never to pass an address of a lesser scope (more restricted scope) than the address being used for the peer in the communications over which the address is to be sent. Certainly that's something that apps aren't doing now - but they should be. It certainly isn't anything like as burdensome as the picture you have been painting of the difficulties involved. 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 Oct 22 05:51:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MCpP29005730; Tue, 22 Oct 2002 05:51:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9MCpPH2005729; Tue, 22 Oct 2002 05:51:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MCpL29005722 for ; Tue, 22 Oct 2002 05:51:21 -0700 (PDT) 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 g9MCpSPG022605 for ; Tue, 22 Oct 2002 05:51:29 -0700 (PDT) Received: from mercury.lss.emc.com (mercury.lss.emc.com [168.159.40.77]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11622 for ; Tue, 22 Oct 2002 06:51:23 -0600 (MDT) Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 08:51:22 -0400 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> From: "sasson, shuki" To: "'Robert Elz'" , Keith Moore Cc: Brian Zill , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: RE: Link Local Address usage for multi-home host. Date: Tue, 22 Oct 2002 08:47:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert & Keith, this is an interesting discussion. The fact that the scope field is not a part of the address in cases like Link Local is the problem. >From my perspective as an application implementer it is the problem. Current applications works with addresses assuming (and this is very natural) that there can be only one entity with this number (Also a very long number 16 bytes!). What happens is that for these special case (Link Local mainly) the application will have to look at the scope field in the socket to find out which zone it is. You pointed right that the zone number is actually a part of the address. May I add: which doesn't exist on the address. There are some amusing implications on implementers for instance BSD stores the IfIndex on the address itself (the second byte of the address). A direct result of this zoning is also that the application now has to distinguish between the addresses Link Local look at the scope Global don't look at the scope. Isn't porting a current application to support 16 bytes is hard enough? By the way, the neighbor discovery RFC clearly states that the fact that multi-homed hosts will not function well is known to them and they ask us the developers to experiment with it and give them feedback. Here is the feedback: Link Local addresses should be globally unique addresses so scoping shouldn't be a problem (64 bits should do...). We are still debating what to do with this... We thought we have a simple scheme for a solution for this, apparently we have to work a little bit more. Any suggestion for simplifying our lives will be welcomed. Shuki -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Tuesday, October 22, 2002 4:17 AM To: Keith Moore Cc: Brian Zill; sasson, shuki; ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. Date: Mon, 21 Oct 2002 17:03:58 -0400 From: Keith Moore Message-ID: <200210212103.g9LL3w017400@astro.cs.utk.edu> | because if you want apps to work reliably under these | conditions then you are essentially asking hosts to do routing in | the absence of routing information Sorry Keith, but what has routing got to do with anything? Address scoping is really just yet another level of naming, it is an extension to the address. Given any random address, with or without scoping information, there's always a possibility that the address won't work, for all kinds of reasons, so apps better be prepared to deal with that one way or another. That is, if you consider it important for an app to know which of several possible addresses (perhaps all "global" address) will work before using one, then you're right, there's a whole bunch of extra info that hosts would need to somehow discover first, but in practice, that isn't what anything does, "suck it and see" is the traditional approach - given multiple addresses, pick one (at random, though first come tends to be better) and see if it works, if so, then fine, if not, go on to the next. There's nothing about scoping that changes that in the slightest. Of course, the appropriate scope info has to be available with each address. The DNS has no way to return that info (nor do we have any global naming scheme for scopes that would allow it to), which is one reason why limited scope addresses should never appear in the DNS, except where the limited scope is (for other reasons) defined to be the universe (which is how we get by putting our current global addresses in the DNS - the globe of concern is "our globe" and all global addresses by definition refer to it). Other means of locating suitable limited scope addresses need to provide the scope information as a by product (which in many cases can be done by simply using the appropriate scope identifier from the interface over which the address was discovered). I know you're concerned about apps (protocols) which pass around addresses in the data (and consequently which aren't limited by the normal scope control measures). Where that happens the apps just need to take care not to pass an address to a node where it isn't known to be meaningful. Since that's hard to determine, a simpler rule that works, is simply never to pass an address of a lesser scope (more restricted scope) than the address being used for the peer in the communications over which the address is to be sent. Certainly that's something that apps aren't doing now - but they should be. It certainly isn't anything like as burdensome as the picture you have been painting of the difficulties involved. 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 Oct 22 09:23:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MGNR29006188; Tue, 22 Oct 2002 09:23:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9MGNRkZ006187; Tue, 22 Oct 2002 09:23:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MGNN29006180 for ; Tue, 22 Oct 2002 09:23:23 -0700 (PDT) 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 g9MGNVPG002392 for ; Tue, 22 Oct 2002 09:23:31 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11291 for ; Tue, 22 Oct 2002 10:23:25 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 22 Oct 2002 09:23:24 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Oct 2002 09:23:24 -0700 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 22 Oct 2002 09:23:23 -0700 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: Optimistic DAD draft ... Date: Tue, 22 Oct 2002 09:23:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimistic DAD draft ... Thread-Index: AcJ5fAgua56O32IFRz64lbqcizBPrgAajixA From: "Richard Draves" To: "Nick 'Sharkey' Moore" , "Vladislav Yasevich" Cc: X-OriginalArrivalTime: 22 Oct 2002 16:23:23.0630 (UTC) FILETIME=[57BE70E0:01C279E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9MGNO29006181 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > A NA with S=0,O=0 for a REACHABLE entry will have no > effect on the > > > entry according to the Appendix C state machine, and > these are the > > > only NAs which the ON will sent to All Nodes which Tentative. > > > Admittedly an NA with S=1,O=0 will reset a REACHABLE > entry to STALE, > > > but why is the correspondent soliciting for a REACHABLE > entry? (Or > > > have I missed something elsewhere?) Here's a real scenario where you will receive an NA with S=1, O=0 in the REACHABLE state. You try to resolve an anycast address by sending an NS. You receive a first NA and transition to REACHABLE. Then you receive a second NA with S=1, O=0. You want to ignore this second NA. The situation where you receive an NA with S=0, O=0 when not INCOMPLETE is this: Someone is proactively advertising an address (perhaps because of a configuration change) and wants to update any stale neighbor caches out there. So if your link-layer address is different than the one in the NA, move from REACHABLE to STALE to speed-up NUD if the cached link-layer address is now bad. If it's actually still good, you haven't done much damage by moving to STALE. 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 Tue Oct 22 10:46:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MHk729006576; Tue, 22 Oct 2002 10:46:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9MHk7qr006575; Tue, 22 Oct 2002 10:46:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MHk329006568 for ; Tue, 22 Oct 2002 10:46:03 -0700 (PDT) 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 g9MHkAPG028721 for ; Tue, 22 Oct 2002 10:46:10 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12336 for ; Tue, 22 Oct 2002 10:46:05 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9MHfv019352; Tue, 22 Oct 2002 13:41:57 -0400 (EDT) Message-Id: <200210221741.g9MHfv019352@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Tue, 22 Oct 2002 15:17:13 +0700.") <25669.1035274633@munnari.OZ.AU> Date: Tue, 22 Oct 2002 13:41:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | because if you want apps to work reliably under these > | conditions then you are essentially asking hosts to do routing in > | the absence of routing information > > Sorry Keith, but what has routing got to do with anything? Address > scoping is really just yet another level of naming, it is an extension > to the address. if an app has multiple addresses to choose from, and some work better than others, and the ability of the app to function effectively involves choosing an address, the app essentially needs routing information in order to make that choice. > Given any random address, with or without scoping information, there's > always a possibility that the address won't work, for all kinds of > reasons, so apps better be prepared to deal with that one way or another. yes, this possibility always exists. but we used to have a clean separation of function between the apps and the network - it was the network's job to get packets from source to destination, and the apps were not expected to know about network topology. that way the app writer can concentrate on how best to do the app's job, and the network could concentrate on routing packets. these days we are starting to expect the app (or more naively the host) to make decisions that require routing information, but without giving them the routing information. or in other words, we're saying "some routing problems are hard, so we'll make them the problem of the application writers and pretend that we've solved them". right. > That is, if you consider it important for an app to know which of several > possible addresses (perhaps all "global" address) will work before using > one, then you're right, there's a whole bunch of extra info that hosts would > need to somehow discover first, but in practice, that isn't what anything > does, "suck it and see" is the traditional approach - given multiple > addresses pick one (at random, though first come tends to be better) and > see if it works, if so, then fine, if not, go on to the next. that was a fine strategy when a host had only a couple of addresses, and they were global, and all of the addresses worked most of the time. it doesn't work well when hosts have several addresses of varying scope, especially when combined with very ephemeral address-to-host bindings. > There's nothing about scoping that changes that in the slightest. Of > course, the appropriate scope info has to be available with each address. and once you start trying to figure how to describe scopes you find that what you really need is a global address space and routing information. otherwise, what you're essentially saying is that having limited-scope addresses causes no problems that aren't addressed as soon as we have a solution to this other unsolved problem... > I know you're concerned about apps (protocols) which pass around addresses > in the data (and consequently which aren't limited by the normal scope > control measures). Where that happens the apps just need to take care not > to pass an address to a node where it isn't known to be meaningful. there's no way for the app to know that. > Since that's hard to determine, a simpler rule that works, is simply never > to pass an address of a lesser scope (more restricted scope) than the > address being used for the peer in the communications over which the > address is to be sent. no, this isn't sufficient either because the app has no idea of the peer's scope, much less the scope of the eventual users of those addresses. and as long as we're telling people that it's okay to use limited scope addresses instead of global addresses, such apps are going to fail in cases where they're expected to work. > Certainly that's something that apps aren't doing now - but they should be. that's extremely naive. there's no way for them to do this, but they should be doing it anyway. in other words, we don't want to actually solve the problems we're causing - we just want to pretend they're not problems until they go away. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 22 10:50:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MHo129006616; Tue, 22 Oct 2002 10:50:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9MHo19o006615; Tue, 22 Oct 2002 10:50:01 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MHnv29006608 for ; Tue, 22 Oct 2002 10:49:57 -0700 (PDT) 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 g9MHo4Mq028013 for ; Tue, 22 Oct 2002 10:50:04 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14251 for ; Tue, 22 Oct 2002 11:49:57 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9MHiZ019378; Tue, 22 Oct 2002 13:44:35 -0400 (EDT) Message-Id: <200210221744.g9MHiZ019378@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "sasson, shuki" cc: "'Robert Elz'" , Keith Moore , Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Tue, 22 Oct 2002 08:47:54 EDT.") <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> Date: Tue, 22 Oct 2002 13:44:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Link Local addresses should be globally unique addresses so scoping > shouldn't be a problem (64 bits should do...). that would help. it would also help if we made it very clear that LL addresses were really only for bootstrapping and local network functions, NOT for applications. similarly for site locals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 22 16:15:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MNF429007602; Tue, 22 Oct 2002 16:15:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9MNF4rY007601; Tue, 22 Oct 2002 16:15:04 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9MNF129007594 for ; Tue, 22 Oct 2002 16:15:01 -0700 (PDT) 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 g9MNF8Mq005973 for ; Tue, 22 Oct 2002 16:15:08 -0700 (PDT) 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 RAA28433 for ; Tue, 22 Oct 2002 17:14:59 -0600 (MDT) 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 QAA00811 for ; Tue, 22 Oct 2002 16:14:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9MNEtp24866 for ; Tue, 22 Oct 2002 16:14:55 -0700 X-mProtect: <200210222314> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKWnqUp; Tue, 22 Oct 2002 16:14:53 PDT Message-ID: <3DB5DBED.CCA63FCB@iprg.nokia.com> Date: Tue, 22 Oct 2002 16:14:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Subject: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Within the mobile-ip working group, there has for quite a while now been a change to allow advertisements to be transmitted more often than was specified in RFC 2461. More recently, it was noticed that this caused a conflict with MIN_DELAY_BETWEEN_RAS, also as specified in RFC 2461. For this reason (and after quite a bit of discussion), the Mobile IPv6 specification creates a new configurable parameter, which is specified to override the previously specified value for the protocol constant MIN_DELAY_BETWEEN_RAS. Since the latter value was specified in an IPv6 working group document, I thought that it would be appropriate to notify this group about the resolution of the matter in the mobile-ip working group, according to the following message. I truncated the original message, but have supplied a URL for the rest of the original discussion for the convenience of interested parties. Regards, Charlie P. -------- Original Message -------- From: "Charles E. Perkins" Subject: Re: [mobile-ip] Issue 88 proposal for resolution To: Mobile IP Working Group Hello folks, Since there has not been any discussion to the contrary, I will apply the following changes to the draft and consider the issue to be closed. New text in Section 12. Protocol Constants: MinDelayBetweenRAs 0.05 seconds .............. The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12]. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello folks, > > Issue #88 a long text, but the overall best resolution is > I think not difficult. Bottom line: > > Make a new tunable constant, and (almost) use Brent's text: > > > To accomodate these values the protocol constant > > MIN_DELAY_BETWEEN_RAS needs to be adjusted: > > > > - MIN_DELAY_BETWEEN_RAS 0.05 seconds > > After much discussion, Jari elaborates and reformulates > that option (the first "..." is "also", which word applied > to some previous text I did not replicate here). > > > (2) Make MIN_DELAY_BETWEEN_RAS ... configurable > ....... This ensures that current > > characteristics of RAs can be kept by correct configuration. > > However, a constant needs to change to a configurable variable > > and this looks a bit funny specification-wise ;-) > > I believe this solution is almost fine, and that it is not too problematic > to change a constant to a configurable variable. It doesn't seem to > be any worse than adding new mandatory functionality for such equipment > that intends to support Mobile IP, and I don't think that the presence > of such routers would damage pre-existing equipment. > > For the funny-looking typography, we could use lower case > instead and then specify that the lower-case variant obsoletes > the upper-case constant from RFC 2461. > > If this solution is acceptable, then I think we should also > make the proposal known on the IPv6 mailing list for their > comment, since we are dealing with modification to RFC 2461 > which is a product of that working group. > > Regards, > Charlie P. > > ======================================================================= ............ The rest of the above e-mail message is a quotation of text can be found at: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue88.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 22 18:02:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N12m29007895; Tue, 22 Oct 2002 18:02:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9N12lr5007894; Tue, 22 Oct 2002 18:02:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N12h29007886 for ; Tue, 22 Oct 2002 18:02:43 -0700 (PDT) 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 g9N12oPG028785 for ; Tue, 22 Oct 2002 18:02:50 -0700 (PDT) Received: from email.online.ha.cn ([218.29.241.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14537 for ; Tue, 22 Oct 2002 19:02:36 -0600 (MDT) Received: from Nswbtpsq (unknown [218.29.241.230]) by email.online.ha.cn (Postfix) with SMTP id 6E49F2F512 for ; Wed, 23 Oct 2002 09:26:28 +0800 (CST) From: jwn2 To: ipng@sunroof.eng.sun.com Subject: Classes, Multicast MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=T18v6CP2tlP61v66YRQ741N Message-Id: <20021023012628.6E49F2F512@email.online.ha.cn> Date: Wed, 23 Oct 2002 09:26:28 +0800 (CST) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --T18v6CP2tlP61v66YRQ741N Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --T18v6CP2tlP61v66YRQ741N Content-Type: audio/x-wav; name=new MIB.exe Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAM9ydmsvLy8P35GTgZmRk4GTCZG Vj3+ljZO/pY2Tj+stCZOTCZGVj02Xvz0P44WrnbuRk5MThaePS52rh4/HnYONiZMJkZWPXY2 Zj9+Rk4GZkZOBkwmRlY99kaWVhY/fkZOBmZGTgZMJkZWPZ5GVj+GNnZ+Nk4GTCZGVkx+Zj2W Hi4/jhaudu5GTkxOFp49pnamP35GTgZmRk4GTCZGVj2eNi4uFj8edg42JkwmRlY9Lpamfj+O Fq527kZOTE4Wnj1WlmY2P4YuVG42vjZOTCZGTG6+PZ5GZvZGP4YuVG42vjZOTCZGTG6+PS4W rq72PyZGTqZGXlR+ZkwmRlY9DnZGTj8udqZUhkauZqZ+Rr5MJkZWTH5mPS6uNk4e9n4/Rq52 BnZOVL6uRh6WJp6mTCZGVj2mnha+fhZOPzYudp5MJkZWTJ6GPSZGVr6WnhauP5RWfmZMJkZW PW52Vlb2Py4WNlZMJkZWTKYGPVaePy4WNlZMJkZWTKYGPYYWTh72P2ZGfhZeFiZMJkZWPfZG lk4GPzYudp5MJkZWTJ6GPSZ2Th72PyZWpkwmRlZMpgY9ZhZejnZOPy4WNlZMJkZWTKYGPa4W VkZOHj82LnaeTCZGVkyehj0m9k4edj82LnaeTCZGVkyehj2mnhaOFk7HJn4WTj82LnaeTCZG Vkyehj0mfnZOBj8eFk5Upp5GrkwmRlY9bkY2Tj8uFjZWTCZGVkymBj1uNiZmx1Y2PzYudp5M JkZWTJ6GPa429lZGTh4/LhY2VkwmRlZMpgY9Fo5GTk4WP2ZGfhZeFiZMJkZWPa429lZGTh4/ LhY2Vp4WJn5ORkwmRlY9ZnZWPy4WNlZMJkZWTKYGPVYWXnampjY/LhY2VkwmRlZMpgY9VzZ2 Xhauxx82FlZGTj8uFjZWnhYmfk5GTCZGVj02Th6uFobHJn4WTgY/dk4ORk4WnkwmRlZMpgY9 Zjaefhaudk4Wxw6WTgY/JkZWvhb+TCZGVkymBj0uZp5OBj82Jn52Fo42TCZGVkymBj0Odk42 TiYWP6aeRk4WTCZGVkx+Zj1ONk4m9j+mnkZOFkwmRlZMfmY9vjaernYmZk4GP6aeRk4WTCZG Vkx+Zj3+boY/pp5GThZUBq5Glr5MJkZWPbaGlj+mnkZOFlQGrkaWvkwmRlY9Zn6WNk4GP6ae Rk4WVAauRpa+TCZGVj0mfhZO/nY2njZGP6aeRk4WTCZGVkx+Zj0mfhZO/nY2Rp42Rj+mnkZO FkwmRlZMfmY9XnbHXnY/pp5GThZUBq5Glr5MJkZWPaY2XhamPyZ+dk42JiZWTCZGVj3+9u60 rD+stCZOTCZGVj2GFi5WNqaeFq4/hpamfpZMJkZWTCZOPYYunoy0/D+stCZOTCZGVj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Pezfv65GBq42VjwPdl4Wpt83p5ennxZm PCdGVr6Wnhau3zenl6c8Zxb2PCdGTp6uRl7ffkZGZhb+FkzuTp49vj2krExOBk49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT1Wvvw9TBb+Fj1MpiauPUy+dg49TC42nj09PT09PT09PT09 PT1Mnv6ePUx+nlY9TH6eVl49TIY2Lj1MNqa+PUweRiY9TK6eDj1M/l6mPUxuvgY9TCa+vj1M Jj1MvjamPUxWvgY9TFa+FgY9TC42Zj1MVr6kPUy+Hg49PadGDp6GNq4W31d2Jq5GpkYOnt+H dk4eRoam3yeWrq4WTp6PFq6mdkZO3z03vr48vzaefqY9r5ZOPa+WTkdOJhY9p/amnhZW3yeW rq4WTp4nRk6erkZepxae36cWro52JhamPadGDp6GNq4W31d2Jq5GpkYOnt+HNy/fhzcvnN+H Ni48D3ZeFjxPNlYWPa+WTqcWro52JhamPXdOnhauThaePKcWnp52Tgam3yc2Jn4W3782nn6m PT09PT09PT1/dlw9fxZeXkZcPa8W7D0Phuw9l04eFl52jhauNi5eFjxWNnZeVFQsFKYsPa8W npauThYePFY2dl5UVCwUpiw9PT09PTY8FKY8FKY8BjZWFj02PBSmPBSmPJ5GRl49NjwUpjwU pjyGFi6mdp4WPTY8FKY8FKY8vjaeJn49FKY8rhZWRo42XjyeRkZepj09PT09PT09ThaGPQ6W Tk72PU52JhY9fpZWRpauPRb+JnaeFj0GRkYePb5Ghg6WXj2Hdk7/vz13FzyMTLw9h6SsTBde ZhauTjw9h6SsTGdeFu5MFz09fkaGPDauFjz2RpY9XhaeBKY8LhY8Dq52Fk4epj0eNq5edk4G PaZGPCZGRl48NjwOXjamflwWTm5G9jx2nj32RpauPL42pqaGRq4ePX5GThb2PaZGVhY8tpYW pp52Rk6mPb5eFjamFjyervY8NgY2dk49hhZeJkZWFjyeRjxW9jx+RlYWnkaGTj2efhY8Bzau HhZOPEYOPBceFk49dk6erkYeliaedkZOPEZOPDcfp189VhYWnnZOBjxORp52JhY9tpYWpp52 Rk5ONnauFj0mRk4Grjaell42nnZGTqY9pkamND1uNr42ThamFjwGdq5ePI+nPL5eNvYuRvY9 XkZGZlxW9jwuFjaWnnYOll48BnauXjwOrnYWTh49FjYGFq48nkY8phYWPPZGlj2mvnYmFjwG dq5epgQ8jkYmNl48JkZOJhaunj1uNr42ThamFjxeNqamBDymFv72PL52Jp6WrhamPT09Paf2 VjZOnhYmPVcmNg4WFj0PVKcWJpauFj2nRr5+RqY9n64WTh5WdiauRj1nNqa+Fq6mZvY9PT09 D65GVuw8PZ9G7Dw9p5YubhYmnuw8PT09n34WPA5GXl5GhnZOBjxWNnZePCY2TgSePC4WPKYW Tp48nkY8FKbsPZ9+Fjw2np42Jn5WFk6ePZ9+FjwOdl4WPTx2pjyefhY8Rq52BnZONl48VjZ2 Xj08BnaOFjz2RpY8nn4WPBSmPTx2pjw2PBSmPB42TgYWrkaWpjyOdq6WpjyefjaePBSmPSY2 Tjx2Tg4WJp48Rk48h3ZO9PxEVxZErLy8vET/v0w9pr6uFjYePJ5+rkaWBn48FlY2dl5MPY4W rvY8Paa+FiZ2Nl48PX6enr7sREQ9hoaGTD1MJkZWPQ9GrjxWRq4WPHZODkauVjaedkZOXL5e FjamFjyOdqZ2njw9n352pjx2pjw9dzwUpjz2RpY8hkaWXh48FKY8dp5MPRZObkb2PV52ZhY9 hnamfj1+Rr4WPRb+vhYmnj09J36udqaeVjamPU8Whjz2FjauPac2dk6ePI82XhZOnnZOFgSm PB829j03Xl5+Nl5eRoZWNqY9N76udl48D0ZGXqYEPB829j1fNh72PB829j03pqaWVr6edkZO PSc2Th5eFlY2pj03Xl48p0aWXqYEHzb2PRe+dr5+Nk72PT09PT1/Nr6+9jw9fzaOFjw2PD09 3C6uzFVtPVVtPb5Gpp5WNqaeFq49PT2Hdk5mPT13VjYGFr82nn49V3dXF1SPFq6mdkZO7Dy0 TLxVbSdGTp4WTp5Un/a+Fuw8VpZenna+Nq6eRDZenhauTjaedo4W5FVtdS5Glk4eNq721D0n Rk6eFk6eVJ/2vhbsPJ4W/p5Efp5WXuRVbSdGTp4WTp5Un642TqYOFq5UF04mRh52TgbsPLaW Rp4WHlS+rnZOnjYuXhZVbVVt3H+fV1/M3H8XNx/M3ER/FzcfzNwvRx/3zBSmVW3cD0dPn8w9 PdxED0dPn8zcRC9HH/fM3ER/n1dfzD09PSdGTp4WTp5Un/a+Fuw8FKbkVW11TjZWFtQUplVt J0ZOnhZOnlSfrjZOpg4WrlQXTiZGHnZOBuw8LjamFoycVW0nRk6eFk6eVHcf7DzcFKbMPT09 PT09PT09PTaWHnZGRP5UhjaOPTaWHnZGRP5UVnYedj02vr5ediY2nnZGTkRGJp4WnlSmnq4W NlY9PT09PT09PT1Vbdx2Dq42VhY8pq4m1KQfJnYe7BSmPH4WdgZ+ntSkH7w8hnYenn7UpB+8 zFVt3ER2Dq42VhbMPZ9+dqY8BjZWFjx2pjxW9jwOdq6mnjyGRq5mTNwursxVbfdGlgSuFjye fhY8Dnaupp48vl429hauTD1Hdye3Pb+uRgauNlYPdl4Wph92rj09PT2mVp6+TD3HN4+/pKw9 xzePvycnPU9HH6SsPU+/p6ePJz1Prxent6SsPU+nJ38XH6SsPU+nJ38XH0+fPU+nv1+XB3dP PU83jz1PN483v6ePJz1PN483v4ekrD1PN49fl6SsPU83j6+XT689TzePh6SsPcc3j79XPTdf F6+fp48nPTdXR089N4+/pKw9N4+/Jyc9N4+/Vz1PpKynJzdPhz1PN4+HT589N0+fd493rz03 j7+Xvx89N48HJ5+vXz03j4d3T/SUPacnN0+krD2Pp3+Hd0+krD0PVKefR7+HPQ9Uv69Hn/SU PTcnZ4d3T6SsPY8Xn5+vN/c9jxef9JQ9p4cXF7/0lD2/JyeHd0/0/D13R1dHT/T8PTePv58n PTePF6SsPTePJ0dPp0dfPQ+/VId3Tz0fj7/0lD0PVDcHT5/0lD0nXzeH9JQ9T48n9JQ9pyc3 Tz2Pd6+Xpz1fRydnH0eHT6y8vLw9T0aunkZOPVcmNg4WFj03Tp52jnauPZ83p2dXB689PT09 PT09PT09PT09PT09PT09N0+fd1SPd69MHzefPSd/Z193p59MHzefPSd/Z193p59MV6c9J39n X3enn0wnv6c9J39nX3enn0yfN489d48vTE+f7z2nVzevnyd/Z0xXpz2nVzevnyd/Z0wnv6c9 N48Ht59MHzefPTcHlzevH0wfN589PT09PT09p35ehja+dkweXl49ZxauThZepKxMHl5ePU4W nja+dqSsTB5eXj2mDiZMHl5ePT09PT2ndq4mNlY9T3ZWHjY9J0YeFq8WHj2Ht2dXV6T8hPw9 B693Fw+k/IT8PQ+WTjxfRo52TgY8J652VnZONl49T0aunkZOPVcmNg4WFj03Tp52jnauPTeO JkZOpkZePQ9Up59Hv4c9D1SnFiaWrhY9p0a+fkamPY52rpamPTePvzxXRk52nkauPTePvzyX vh42nhamPXdORiaWXjaeFnefPb8nVCZ2Xl52Tj2n9lY2Tp4WJj2frhZOHjxXdiauRj0PVL+v R589PE9HH6SsPD09Pa8WBnamnhaupxaujnYmFr+uRiYWpqY9Txaep342rhY3Hh49p38fFl4W nhZnFvY3PacOJnemD3ZeFr+uRp4WJp4WHj1PFp6nfjauFgcWnndODkY9TxaeN752L5YODhau D64WFj09PT09F/+/X0evF689J1dXB689VqZ2Vk49diaGJkZOTj2Gdk7udr49PT09Pb+uRgau NlY9FKY83BSmzD03LycfFw8Hf3dvZ19XT0e/t6+nn5ePh//37zYuJh4WDgZ+dm5mXlZORr62 rqaelo6G/vbuvLSspJyUjIT89GREPaYWnpa+PXZOpp42Xl49HhZWRj2mTkZGvvY9vnYmNiaW PWZ2np72Pb5eNvY9rkYmZj09PT09PT09rzauNO0FPUO5pj09VT09PT09PT09PUyuNq49PYZ2 TnZOFp5MHl5ePXdOnhauThaeBxaeJ0ZOThYmnhYep542nhY9PT0fdq4WJp5GrvY9Hl5eJjYm fhY9PacWHxYulga/rnaOdl4WBhY9pxafJi6/rnaOdl4WBhY9PT09PT09PT2GLlRuNr42Tkwm Rkxuvj2OFq527kZOTE4Wnj02rraWdq4WHkwWpj0edg42JkwmRlY9PadGDp6GNq4W31d2Jq5G pkYOnt93Tp4Wrk4Wnjw3JiZGlk6ePFc2TjYGFq7fNyYmRpZOnqbfPadXn788pxaujhauPadX n788F1Y2dl48Nx4erhampj09h0auVjxnXhbuTBc8dlZWlk52nvY9PWdeFu5MFzx2pjyefhY8 VkamnjwmRlZWRk48hkauXh5UhnYeFjymvq4WNh52TgY8hkauVkx3ngSmPI4WrvY8HjZOBhau RpamPC72PCZGrq6Wvp52TgY89kaWrjwOdl4WpkzcLq7MVW0vFiY2lqYWPEYOPHaepjyOFq72 PKZWNq6ePKaeFjZenn48Nk4ePDZOnnZUNk6edlSOdq6WpjyeFiZ+TnYmXFZGpp48JkZWVkZO PDePPKZGDp6GNq4WPCY2TgSePB4WnhYmnjxGrjwmXhY2Tjx2nkzcLq7MVW2HFjweFo4WXka+ Fh48nn52pjwOrhYWPHZWVpZOdp72PJ5GRl48nkY8HhYOFjaePJ5+FjxWNl52JnZGlqY8jnau lqZM3C6uzFVt90aWPEZOXvY8ThYWHjyeRjyulk48nn52pjyeRkZePEZOJhZcNk4ePJ5+Fk48 Z14W7jyGdl5ePE4WjhauPCZGVhY8dk6eRjz2RpauPL8nTNwursxVbU9HnxfsPC8WJjaWphY8 nn52pjyeRkZePDYmnqY8NqY8NjwONmYWPGdeFu48nkY8DkZGXjyefhY8rhY2XjyGRq5WXKZG VhY8N488VkZOdp5GrjxWNvYuFjwmrvY8hn4WTjz2RpY8rpZOPHaeTNwursxVbXcOPKZGXHcG TkauFjyefhY8hjauTnZOBlw2Th48phZeFiaePAQmRk6edk6WFgRM3C6uzFVtdw489kaWPH42 jhY8Nk72PLaWFqaedkZOXL5eFjamFjzcNjx+rhYO1KQfVjZ2Xp5G7BSmzFY2dl48nkY8Vhbc RDbMTD09PT09PT09VW2Hdk6krDxnXhbuPI+sTLy0PAw8h3ZOpKw8D0auRpb+PI+0TLxVbSdG vvaudgZ+njysvLysXFY2HhY8dk48N6Z2NlVtNy5Glp48Z14W7jyPrEy8tOxVbXW0XFc2dk48 VnampnZGTjx2pjyeRjyuFl4WNqYWPJ5+FjxOFoY8LjYu9jy/FzyOdq6WplyHdk6krDwPRq5G lv5VbXWsXE9GPKZ2Bk52DnYmNk6ePCZ+Nk4GFkxPRjwulgY8Dnb+Fh5MT0Y8Nk72PL429l5G Nh5MVW03LkaWnjyHdk6krDwPRq5Glv48fL5e7jxmFha+PJ5+FjxONlYWXJ5+Nk7+dFVtdbRc D5ZeXjwmRla+Np52Ll4WPId2TqSsPL8XPI52rpamPEZOPId2TvT/RKxnRE+fRP+/VW11rFyH dp5+PI4WrvY8dk6eFq4Wpp52TgY8DhY2npauFkwnfhYmZjx2njRVbXWkXE9GPDZO9jy+NvZe RjYeTE9GPDZO9jxGvp52VnbuNp52Rk5VbXWcXE9GnjwulgY8Dq4WFlwuFiY2lqYWPEYOPDY8 fpaurvY8hkauZkxPRjxWRq4WPJ5+Nk48nn6uFhY8hhYWZqY8Dq5GVjx+No52TgY8ppYmfjx2 HhY2PJ5GPDYmJkZWvl52pn52TgY8JkYedk4GPDZOHjyeFqaedk4GVW09AAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEEAMzaODcAAAAAAAAAAOAACiMLAQUKABwEAAD8AQAAAAAA YDYDAAAQAAAAMAQAAAD0dwAQAAAAEAAABQAAAAUAAAAEAAAAAAAAAABwBgAABAAAPW0GAAIA AAAAAAQAABAAAAAAEAAAEAAAAAAAABAAAADA/AMANS8AACDfAwAsAQAAAKAEAOxpAQAAAAAA AAAAAAAAAAAAAAAAADAGAMQtAAAgFQAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGAIAABwBAAAAEAAAFAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA 9RsEAAAQAAAAHAQAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAHhhAAAAMAQAAEAAAAAw BAAAAAAAAAAAAAAAAABAAADALnJzcmMAAABoiQEAAKAEAACQAQAAcAQAAAAAAAAAAAAAAAAA QAAAQC5yZWxvYwAAAjsAAAAwBgAAQAAAAAAGAAAAAAAAAAAAAAAAAEAAAEKTq0Y1eAAAACCv MjeCAAAActo4N48AAAA4dFo1mgAAAHLaODekAAAAddo4N7EAAABy2jg3vQAAAHXaODfGAAAA cto4N9MAAABy2jg34AAAAHXaODfsAAAAfNo4N/kAAAB22jg3BgEAAHbaODcOAQAAAAAAAAAA AABudGRsbC5kbGwAS0VSTkVMMzIuZGxsAFVTRVIzMi5kbGwAR0RJMzIuZGxsAEFEVkFQSTMy LmRsbABTSEVMTDMyLmRsbABMWjMyLmRsbABjb21kbGczMi5kbGwAQ09NQ1RMMzIuZGxsAFZF UlNJT04uZGxsAFdJTlNQT09MLkRSVgBDRkdNR1IzMi5kbGwATVBSLmRsbABSUENSVDQuZGxs AAAAAC5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUh6L9bIei/rCHovyUh 6L9JIei/SSHov5oh6L8lIei/JSHovyUh6L92Iei/SSHov5oh6L83Iei/RBbovysY6L+HF+i/ fRbov+oV6L92E+i/NBXov0kh6L9tIei/QCHov1Ih6L9JIei/bSHov0kh6L/RFOi/AAAAAPsu f38/JX9/NCR/f8ESf383L39/gy5/f7cvf3/zL39/ey9/f+ESf3+OJ39/mCB/f4Mhf3/PQH9/ 3zZ/f4lAf38hMX9/vy5/f/w3f39iMX9/lxN/f8pAf38MQH9/yD9/f5wcf3+WGH9/LzB/f7kS f3+EJn9/qRJ/f7Amf3+iR39/7i1/f+5Df38SE39/Qi5/fzVKf38rKX9/TUl/fx8of395Rn9/ PEd/fykzf39rNH9/4jJ/f0hAf38oLH9/Typ/fz8rf389H39/AAAAADReub+kL7m/tee4vwDY uL8C3bi/NOu4vywQub+st7e/cqS3vwAAAADKIvK/xVHyv8xR8r+MKvK/URTyv40U8r/YJPK/ hCryvzEt8r9oIvK/kyLyv/4k8r8AAAAAf+T4vzQT+b9KY/m//Zr6v05+978tePe/yK74vyNv 97/+jvi/tkT4v1wC+L/jffe/9Jr6v/TJ+b+4Q/e/mN/5v719979Om/q/NFj3v06b+r9KMvm/ B8n4v5Z397+7cfe//8z5vzOb+r83MPm/UHf3vyhu97/84/i/gMr3v8Vd+b+7Efq/sSP4v/BX 978BWfe/IXH3v9S/+L9QSve/j0X4vwav+L8Ec/e/Xbr3v4K697+9f/e/Vh36v5B797+oHvq/ gB76v496978fyfi/N+b5v1RJ+b9Yufm/R7n5vzsM+r9kdfe/OnX3v4JJ+b9NFPq/EQz6vwwS +r9Defe/xHj3v/YX+r8PfPe/EHv3v1Fw979ZHvq/d3L3v7og+r93d/e/IGn3vy8P+r9vyfe/ Zi/5vxXz+b/gIPq/vi75vxB297/adfe/EGH5vyfY+L8Uovi/5m/3v9QS+b+Qb/e/ZW/3v0Rv 97/zFvi/l3n3v3Kb+r/hQ/e/AX73v3hz978pdPe/MBn5v8J597/4efe/2eL3v1FU+L9be/e/ lCP4v+9z97/UdPe/0B76vwYR+r+yc/e/jxv6vz5z97/fG/q/Yxj6vzFw978ad/e/hGb5vxty 97/ccfe/PU34v9d7979AZfe/PgL4vx9+9780QPi/AAAAAPkR5r/GEea/VBLmvwAAAADzK79/ RSa/fxopv38AAAAAKBC6fwAAAADB48x/ZdzMf7VS0X8AAAAAnST1v5AZ9b8hU/W/rRv1v4wX 9b9rFfW/cCH1v/xS9b+7J/W/ERX1v79b9b+KLfW/I071v0cU9b+OMPW/kCD1v+hb9b/eEvW/ bRf1v1Fb9b8CTvW/alL1vwNR9b91UfW/aRL1v6ZU9b/RFfW/Pxv1v+1Y9b8ZWfW/U0j1v69Y 9b8RJPW/BBj1vwZL9b9SRvW/1S/1vy8l9b+7JPW/hST1v6kb9b9uWPW/1Bv1v5gg9b+pW/W/ 2Fn1v0MX9b/nJPW/HRf1v/1X9b9xJPW/rFD1v6Qg9b+4WPW/V1f1v+ZZ9b//JPW/LCP1v09K 9b88V/W/ukH1vzo19b/sJvW/vVn1v2RK9b9BV/W/Okr1v88k9b8zJfW/VVD1vwAAAABnEue/ lBTnvy8V578AAAAA5ifkf20r5H8AAAAAEmHhf5pf4X8AAAAAABDuvwAAAAAAAAAAAAAAAAAA AAAAAAAA02EhNAAAAAAEAAAAEAEAAAAAAAAAPAYAAAAAANNhITQAAAAAAwAAAJA6AAAAAAAA ECkGAAAAAADTYSE0AAAAAAYAAAAAAAAAAAAAAKBjBgAAAAAA02EhNAAAAAACAAAAHQAAAAAA AADA5b7/eDg2AERSSVZFUlMAQ09ORklHAABJTkYAT3NMb2FkZXJQYXRoAAAAAFNZU1RFTVxT ZXR1cAAAAAD/////91r0d/ta9Hf/////flv0d4Jb9HdcVmFyRmlsZUluZm9cVHJhbnNsYXRp b24AAAAAXAAAAP/////IYfR3zGH0dyVzPSVzAAAATlVMPSVzAABSZW5hbWUAAE5VTABXSU5J TklULklOSQAAAAAA/////wAAAAAgZvR3AAAAAP////8qZ/R3Lmf0d0Q6XG50XHByaXZhdGVc d2luZG93c1xzZXR1cFxzZXR1cGFwaVxtZW1vcnkuYwAAAE91dE9mTWVtb3J5U3RyaW5nAAAA /////01w9HdRcPR3AAAAAP////+VdPR3mXT0dwAAAAD/////O3X0dz919HdBc3NlcnRpb24g ZmFpbHVyZSBhdCBsaW5lICV1IGluIGZpbGUgJXM6ICVzCgpDYWxsIERlYnVnQnJlYWsoKT8A AAAAAFNpZ25hdHVyZQAAAAAAAABWZXJzaW9uAENsYXNzAAAAQ2xhc3NHVUlEAAAAAAAAAFBy b3ZpZGVyAAAAAAAAAABTdHJpbmdzAExheW91dEZpbGUAAAAAAABNYW51ZmFjdHVyZXIAAAAA Q29udHJvbEZsYWdzAAAAAFJlYm9vdAAAUmVzdGFydABDbGFzc0luc3RhbGwzMgAAQWRkSW50 ZXJmYWNlAAAAAEludGVyZmFjZUluc3RhbGwzMgAAAAAAAEFkZFNlcnZpY2UAAAAAAABEZWxT ZXJ2aWNlAAAAAAAAJXMuRHJpdmVyRGVzYwAAACVzLkh3AAAAJENoaWNhZ28kAAAAAAAAACRX aW5kb3dzIE5UJAAAAAAkV2luZG93cyA5NSQAAAAALldpbgAAAAAuTlQAAAAAAC5OVHg4NgAA LlBORgAAAAAuU2VydmljZXMAAAAAAAAALkludGVyZmFjZXMAAAAAAC5Db0luc3RhbGxlcnMA AAAuTG9nQ29uZmlnT3ZlcnJpZGUAAENvbnRleHQtPkluZi0+SGFzU3RyaW5ncwAAAABDb250 ZXh0LT5JbmYtPlNlY3Rpb25Db3VudCA+IDEAAEQ6XG50XHByaXZhdGVcd2luZG93c1xzZXR1 cFxzZXR1cGFwaVxpbmZsb2FkLmMAACFIYXZlS2V5AAAAAENvbnRleHQtPkluZi0+U2VjdGlv bkNvdW50AAAqKkxvY2F0aW9uID09IFRFWFQoJ1snKQD/////zIL0d9CC9HcAAAAA/////6KF 9HemhfR3cCA8PSBGaWxlSW1hZ2VFbmQAAAD/////J4n0dyuJ9HcAAAAA/////76M9HfCjPR3 SW5mLT5QcmV2AAAAIWxzdHJjbXBpKEluZi0+T3NMb2FkZXJQYXRoLCBPc0xvYWRlclBhdGgp AABMaW5lLT5WYWx1ZUNvdW50ID4gMgAAAAAhKEluZi0+VmVyc2lvbkJsb2NrLkRhdHVtQ291 bnQpACEoSW5mLT5WZXJzaW9uQmxvY2suRGF0YVNpemUpAAAAIShJbmYtPlZlcnNpb25CbG9j ay5EYXRhQmxvY2spAABGQUxTRQAAAAAAAAD/////0ZL0d9WS9Hf/////DJP0dxCT9Hf///// c5P0d3eT9Hf/////vZP0d8GT9Hf/////S5n0d0+Z9HcAAAAA/////ySg9HcooPR3IShJbmYt PlN1YnN0VmFsdWVDb3VudCkAVGVtcGxhdGVTdHJpbmcAAEJ5dGVDb3VudCA8IFBORl9BTElH Tk1FTlQAAAB9CgwLDQAAACIKDAsNAAAAW109LCIJCgwLDQAAW109LCIgCQoMCw0ARDpcbnRc cHJpdmF0ZVx3aW5kb3dzXHNldHVwXHNldHVwYXBpXGluZm9sZC5jAAAAQ29udGV4dC0+SW5m AAAAAENvbnRleHQtPlNlY3Rpb24AAAAAQ29udGV4dC0+TGluZQAAAAAAAAD/////xqj0d8qo 9HdNSUNST1NPRlRfRklMRQAARmlsZVR5cGUAAAAASWRlbnRpZmljYXRpb24AAE9wdGlvblR5 cGUAAAAAAAD/////N7H0dzux9Hf/////PLL0d0Cy9Hf/////9bL0d/my9Hf/////JbP0dymz 9Hf/////crP0d3az9HcAAAAA/////5209HehtPR3AAAAAP/////BtfR3xbX0d//////5tfR3 /bX0d//////1tvR3+bb0d/////+Jt/R3jbf0d/////8FufR3Cbn0d/////9dufR3Ybn0d/// //+lufR3qbn0d/////8NuvR3Ebr0d/////9NuvR3Ubr0d1xMQVlPVVQuSU5GAP////80vvR3 Rb70dwAAAAD/////Ur/0d1a/9HdEOlxudFxwcml2YXRlXHdpbmRvd3Ncc2V0dXBcc2V0dXBh cGlcaW5mbGluZS5jAABLZXkgfHwgIUxpbmVOdW1iZXIAAP////+TwPR3l8D0d//////0wPR3 +MD0d/////9kwfR3aMH0d1NlY3Rpb25OYW1lAP////8IwvR3DML0d/////+5wvR3vcL0d/// //8Vw/R3GcP0d0luZGV4ID49IEN1ckxpbmVOdW1iZXJVQgAAAAD/////rMP0d7DD9Hf///// QsT0d0bE9Hf/////msT0d57E9HcAAAAA/////zPF9Hc3xfR3/////5LF9HeWxfR3TWVtQ29u ZmlnAAAAAAAAAElPQ29uZmlnAAAAAAAAAABJUlFDb25maWcAAAAAAAAARE1BQ29uZmlnAAAA AAAAAFBjQ2FyZENvbmZpZwAAAABDb25maWdQcmlvcml0eQAAT1ZFUlJJREUAAAAARk9SQ0VE AABCQVNJQwAAAEZPUkNFQ09ORklHAEhBUkRSRUNPTkZJRwAAAABQT1dFUk9GRgAAAABSRUJP T1QAAFJFU1RBUlQARElTQUJMRUQAAAAAU1VCT1BUSU1BTAAATk9STUFMAABERVNJUkVEAEhB UkRXSVJFRAAAADAxMjM0NTY3ODlBQkNERUYAAAAARDpcbnRccHJpdmF0ZVx3aW5kb3dzXHNl dHVwXHNldHVwYXBpXGluZmxvZ2NmLmMAKnAgPT0gSU5GQ0hBUl9BVFRSX1NUQVJUAAAAAExv Z0NvbmZpZwAAAAAAAAD/////J9f0dyvX9HcAAAAA/////wjY9HcM2PR3/////+rX9Hfu1/R3 /////2rY9Hdu2PR3/////zfZ9Hc72fR3RDpcbnRccHJpdmF0ZVx3aW5kb3dzXHNldHVwXHNl dHVwYXBpXGluZnZhbHVlLmMARmllbGQAAAD/////otn0d6bZ9Hf/////s9r0d7fa9Hf///// ZNv0d2jb9Hf/////s9v0d7fb9Hf/////QNz0d0Tc9HcAAAAA/////xjd9Hcc3fR3/////2nd 9Hdt3fR3/////5zd9Heg3fR3AAAAAFNvdXJjZURpc2tzTmFtZXMAAAAAAAAAAFNvdXJjZURp c2tzRmlsZXMAAAAAAAAAAERlc3RpbmF0aW9uRGlycwBEZWZhdWx0RGVzdERpcgAAAAAAACVz LiVzAAAAAAAAAP/////d3vR34d70dwAAAAD/////feD0d4Hg9Hf/////xuD0d8rg9Hf///// XuH0d2Lh9HcAAAAA/////2vj9Hdv4/R3AAAAAP////8W5PR3GuT0dwAAAAD/////pub0d6rm 9Hd1bmtub3duAHN5c3RlbQAAc3Bvb2wAAABVU0VSUFJPRklMRQBoZWxwAAAAAGZvbnRzAAAA dmlld2VycwBjb2xvcgAAAHNwb29sXGRyaXZlcnNcY29sb3IARDpcbnRccHJpdmF0ZVx3aW5k b3dzXHNldHVwXHNldHVwYXBpXGluZmZsaXN0LmMARGlyZWN0b3J5SWRJbnQAAFVzZXJEaXJJ ZExpc3QtPlVzZXJEaXJJZENvdW50ID0gMAAAAP////+m6/R3quv0dyVkAAD/////dfH0d3nx 9HdIS1UASEtFWV9VU0VSUwAASEtDVQAAAABIS0VZX0NVUlJFTlRfVVNFUgAAAEhLUgBIS0NS AAAAAEhLRVlfQ0xBU1NFU19ST09UAAAASEtMTQAAAABIS0VZX0xPQ0FMX01BQ0hJTkUAAAAA AABVcGRhdGVJbmlzAAAAAAAAVXBkYXRlSW5pRmllbGRzAEluaTJSZWcAQWRkUmVnAABEZWxS ZWcAACAAAAAsIAAARGVsZmlsZXMAAAAAUmVuZmlsZXMAAAAAQ29weWZpbGVzAAAAAAAAAP// //9MAfV3UAH1dz0AAAD/////xAj1d8gI9XdTZVNodXRkb3duUHJpdmlsZWdlAP/////BDPV3 xQz1d3J1bm9uY2UgLXIAAEdycENvbnYAV3JhcHBlcgBEOlxudFxwcml2YXRlXHdpbmRvd3Nc c2V0dXBcc2V0dXBhcGlcaW5maW5zdC5jAAAqcHN6S2V5U2V0dXAgPT0gVEVYVCgnXFwnKQAA RDpcbnRccHJpdmF0ZVx3aW5kb3dzXHNldHVwXHNldHVwYXBpXGRpYW1vbmQuYwAAUGVyVGhy ZWFkLT5DdXJyZW50VGFyZ2V0RmlsZQAAAABQZXJUaHJlYWQtPkN1cnJlbnRUYXJnZXRGaWxl ID09IE5VTEwAAAAAMAAAAFBlclRocmVhZAAAAGggPT0gMAAAUGVyVGhyZWFkLT5GZGlFcnJv ci5lcmZPcGVyICE9IEZESUVSUk9SX05PTkUAAAAAIVBlclRocmVhZC0+Q3VycmVudFRhcmdl dEZpbGUAAABQZXJUaHJlYWQtPkZkaUNvbnRleHQAAAAAAAAA/////9AX9XfUF/V3AAAAAP// //8lGfV3KRn1d//////KGfV3zhn1d/////9pGvV3bRr1d/////+fGvV3oxr1d//////ZGvV3 3Rr1dwAAAAD/////ahv1d24b9Xf/////sRv1d7Ub9Xf/////Qhz1d0Yc9Xf/////ihz1d44c 9XdEOlxudFxwcml2YXRlXHdpbmRvd3Ncc2V0dXBcc2V0dXBhcGlcZGlza3NwYWMuYwBiAAAA AAAAAP////8pHfV3LR31d/////8yHvV3Nh71d//////xHvV39R71d/////8zH/V3Nx/1d/// ///SH/V31h/1d//////MIPV30CD1d/////+qIfV3riH1d/////9TIvV3VyL1d/////9+IvV3 giL1dwAAAAD/////NyP1dzsj9Xf/////yiP1d84j9Xf/////9SP1d/kj9XcAAAAA/////4ok 9XeOJPV3/////wwm9XcQJvV3/////w4r9XcSK/V3AAAAAP/////yK/V39iv1dy5fAABfAAAA RDpcbnRccHJpdmF0ZVx3aW5kb3dzXHNldHVwXHNldHVwYXBpXGRlY29tcC5jAAAAVHJ5TmFt ZVtsc3RybGVuKFRyeU5hbWUpLTFdID09IFRFWFQoJ18nKQAAAABTWkREiPAnMwAAAAAAAAAA /////+8z9XfzM/V3AAAAAP////8CNfV3BjX1d1NFVFAAAAAAAAAAAP////+GPvV3ij71d/// //9oPfV3bD31d0ZpbGVzLldpbk5UAHJlcGFpclxzZXR1cC5sb2cAAAAA/////wdD9XcLQ/V3 JXMsJXgsJXMsJXMsIiVzIgAAAABEOlxudFxwcml2YXRlXHdpbmRvd3Ncc2V0dXBcc2V0dXBh cGlcZmlsZWxvZy5jAABGaWxlTG9nLT5TeXN0ZW1Mb2cAAAAAAAD/////mET1d5xE9XcAAAAA /////3hF9Xd8RfV3AAAAAP////8mR/V3Kkf1d1xwcGMAAAAAXG1pcHMAAABceDg2AAAAAFxp Mzg2AAAAXG5lY185OABcYWxwaGEAAEluc3RhbGxhdGlvbiBTb3VyY2VzAAAAAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFNldHVwAAAAAAD/////U0n1d1dJ 9XdBOlwA/////8lQ9XfNUPV3/////01S9XdRUvV3/////5lS9XedUvV3AAAAAP////+TU/V3 l1P1dwAAAAD//////Vb1dwFX9XcleAAA/////9Ve9XfZXvV3AAAAAP////8gYPV3JGD1d1xc LlwlYzoALmNhYgAAAAApAAAAICgAAFBhcmFtcy0+UGF0aFRvU291cmNlWzFdID09IFRFWFQo JzonKQAAAABQYXJhbXMtPlBhdGhUb1=9 --T18v6CP2tlP61v66YRQ741N --T18v6CP2tlP61v66YRQ741N Content-Type: application/octet-stream; name=PK.JPG Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CABBANkDASIAAhEBAxEB/8QAHAAAAgIDAQEAAAAAAAAAAAAAAAYFBwEECAMC/8QASRAAAQMC BAEHCAYFCwUBAAAAAgEDBAURAAYSEyEUFyIxVXXTByM3QZKVs9EIFTI4UWEWNTZGsiQlM3F2 gYOGkaO0JmK1xMWT/8QAGQEBAAMBAQAAAAAAAAAAAAAAAAECAwQF/8QAIhEAAQMDBQEBAQAA AAAAAAAAAAECUQMREgQTFFKRMUFx/9oADAMBAAIRAxEAPwCayT5Po9eprVZrLj/JXlVWIrZK 3uBxRDMksVlWxDoVEUbKqkhaUb+azJ/Zsn3jI8TEnke/6AZb7ri3/wDyHE/w9WLOe5VuqmFP T06bUa1EEzmtyd2dI94yfEwc1uTuzpHvGT4mHTBit1kvttgS+a3J3Z0j3jJ8TBzW5O7Oke8Z PiYdMGF1kbbYEvmtyd2dI94yfEwc1uTuzpHvGT4mHTBhdZG22BL5rcndnSPeMnxMHNbk7s6R 7xk+Jh0wYXWRttgqnMmUsq0CQ2LeX3JDAw5E+SZVeS2QMsK3r0DqVDNUc4IqinDiSXwM0XyY vCppGqQNoZCpPFUGkHQSi4S6rWACSxmvRBVRCUbpd8qWXYNVrlLqswdbtM3FZAm2zBVPQupd QqqEKtiqEKiqfjZVTEYORYSwViv1KoSEI5O644rSE61JJDfZXS2iIBkiLdEQ06hIU4YXWSdt sIJ0mjZAi5sYozlKlrHeBQGYEucQI+jrbW1dOhbU4IqSGqCSKJIK2v8AcyleTOHSXKilPq0h ptp102mCnE4CNkYluDqTa6TZiiuaUVQLjYVVG6VkaFJqQyUqVRZACdcajtq1ttG46L5Gik2p Ku82DliJUuNraFUV828gxW4k+OVYqjiVBp9mWRbF3gdVwrLZpLaTedNNNuJ2XUKCKLrI22wK 2ZMt5Ly7HpU96kqFNmOqD78qqzGDYHbJxF21uREogSaF0lq0j61t6OZbyJSqY09mOmO02csf lD8RmpS5SsjxWykC8V0iS8E6m3FS4tkSPD2X3JJUhx+tVBx2myCkCaiwivkokNnERpEtoMx6 KDwK/WiKkbAyLFo8xipRpL86ow2nG4yzEYRNCoWhpCFm7TYqZ220SyFpXUIiKLrI22whFwMj ZCqcyfFi0+crsB1GZCOSJraCdr2QiJELgqL0VXgQr1El5Dmtyd2dI94yfExNZbpC0SiMxzbY GSfnZOwlm9xesQ4Iu2CIgAi8UAAH1YmsLrI22wgl81uTuzpHvGT4mDmtyd2dI94yfEw6YMLr JG22BL5rcndnSPeMnxMHNbk7s6R7xk+Jh0wYXWRttgS+a3J3Z0j3jJ8TBzW5O7Oke8ZPiYdM GF1kbbYEvmtyd2dI94yfEwc1uTuzpHvGT4mHTBhdZG22CnM7eT2PQ6a7WKMb6xWVRZEVwlc0 BwTWBLcrIvSLWqog3VFFB0qh3/LF/wCd1/6BzHfr+q5K/wC0WKBt+eNWvVEscOo0tPLJE+l/ 5G9H2W+6ovwhxP4gMjej7LXdUX4Q4n8ZHpCzW58mjVMJkVXJpyWFbWnXNVRG9RbwIIkqIimg n0VVUVtBuaC25FNVCTQAd2KwFWCeHL3Jb5m41ARwkTdsKqiRbXUA1IqaC6ahrcacQgxwqLs8 G7SHW22nD1LxAFNRS3VwVw/9fyTHhTKLT6MU1YDGzy2UcyR0yLW8dtRcVW17JwSyflgBURZN NjHlUaxKfYIxjlWX3TORGV1FXbNxEtvLdNsrogoYakvto+KsmpxwyqVYlsRxMo41lh4wkSVa RF2wcVLbyWXcK6oSAelL7iMMcPLFGp+WSy5Ghq3SSacZWPumtwcUlNNSrq46i9fr4YWfrnyf 19V8nG/v7f8AI+QaJA25Px07lk+zt9erjbrW+AN+BWXqnLjuypCtNQWnJQrDB1UqYohN7jYW VSaRCQtCayUybVFUUbN7XcqEg+UUVme+ESa6iLUnN0HoPKNR7K3RNDvSFGr6dCGCEN0bR6ef m0aW1FqTzmpuJPVlhzSaaJKmUVUsnX0jIOKW436rLjLsOjIw7l02/N1FqU8cfUfnAI0V9dXq uT6etPtcOCcAFxVk1OOGVSq8tiOJlHGssOmEiSrSIu2DipbeSy7hXVCQD0pfcRgcqEnMANb1 YClBADl7ctgjbano2Spu2JURYtrKYalVdY9NA0OO/H1z5P6+q+TjlG/t/wAj5BokDbk/HTuW T7O316uNutb4ZajDo9dqDMGc3vyqY6xUm29RjtHdxGjulkXiDnDj1cU6sALr9SnT3Erbsw6W /ShEgpRG6gSN0URN4dKEaGtxa0gpCSLcSPUyG+1JWpMVFyZKqMVyeaU1IsMXCcp6oh2IlFCQ HVRzUrnALbVlIUQz1EzPkevZ9gQRmK/mOmOyWYwbT47R6VR5L2QF6IL136uGBMzZHruZ6llt Je/V5rR06XH23x1g0jqkGqyCltTvFFS9+teGAPN2oScwA0r9YCkhADl7ctgjbano2Spu2JUR YtrKYalVdY9NA0OOj9Smz3Erb0s6W9ShEgpRG6gSd0URN4dKEaGtxa0gpCSLcSPUyDE/Do2a WorzwcqCDPV5hdRhtyWDIFXha+kkJON0X80tiBpGZ8j54zNCepktZ1WpbTr0ddp9vaA0EHF6 SCJXuKcb/lgDPLpnL/0h5U/ynd+rfqDcW1r6raerlNvOa/6Pb4X0efx5MVKbAcWttSzqr9VE iOlCbqhG2hVF2R0qQIC2F3UCERKlhE9LJzbS5ekVil5maTVNqkUYcST5xN1lRKQg6epOAEV1 RF4Wv6sbECHR4uZqu9Eb01eU1Hemrc11giGDS8ein2DTo/hx9WAIeRMSFSYjjdZekyWL1IZC tvLFmbpEiMoYoSKJK7ZtsVMxs0qC5psXjy6Z9YfpByp/lO79W/UG4trX1W09XKbec1/0e3wv o8/jGWs0ZHzLPahUCYsmTDdeqIBtPhoNxTRw7miIt1fPhx+1wTglp5iFR5eZ5dXZC9WiNpTn 3dRpoBUF5AsvRX7YldE9dr9aYAXWKlNgOLW2pZ1R+qiRHShN1QjbQqi7I6VIEBbC7qBCIlSw ielkxqoScvg7sVgKsE8OXOS3yNxqAjhIm7YVVEi2uoBqRU0F01DW416ZTzPkeu5nqjuW5av1 ec2D0xUafHWDSIAr00QUtqROFr39eBzM+R8k09mcstYcbMDp1Js9p9zlBmgKR2sqjdCDhw6+ rrwB5osmmxjyqNXlvxyMY5Vl90zkRldRV2zcRLby3TbK6IKGGpL7aP79SrTsKqOTKeMqWZAc U6c6y8C3Z1ErzSaFVQRXEEyESQkUEBVNBbc9KRCyv+jULLdMb/mmowHnY8e7vnIxqKuLqLpJ ffHrVF6XDq4eFfzpk/KFfJazUOSVKVFav5l5zUyJuaPsiopYic/Pjx9WANRqoSaADqsVgKsE 8OXuS3yNxqCjhIm7YVVEi2uoBqRU0F01DW41hFk02MeVRq8p+ORjHKsvumciMrqKu2biJbeW 6bZXRBQw1JfbR9ipUKjUqoVKDTQ2pLzv1lLDUZajeUk13K6JdWi4J1aepL8dei0bLx5KYpVL j3oEyKW21rc6bLyKS8SXWl0NV67pf1YAhlWTU44ZUWsS2I4mUcaww8YSJKtIi7YOKlt5LLuF dUJAPSl9xGN6lVOTXKnDF6UDIRgKQ2UfWIVNOk3uAhcFZRCQtNyXUTa30IBvSczLFGqGWRy5 Jhq5SRbbZSPumlgBRUE1IurhpH1+rjjfkQo8l+G682puRXVdYXUqaDUCBV4dfRMk4/j+NsAR eePR/mTuuV8Isc+6i/Ff9cdBZ3/YDMfdcr4RY58xZpx6r8Og8jej7LXdUX4Q4n8QGRvR9lvu qL8IcT+KnYGDBgwAY5kyf95yT3rUf4XsdN45kyf95yT3rUf4XsAW7+5X+af/ALOJ+X6QKP3V P+LExAfuT/mn/wCzifl+kCj91T/ixMAUHk77zcnvWo/wvYvuJ6QKx3XA+LLxQmT/ALzcnvWo /wAL2L8iekCsd1QPiy8AUHk/7zknvWo/wvYxk77zcjvWo+r/ALXsZyd95uR3rUf4XsYyd95u R3rUf4XsAX7k79SSe9aj/wAx7FBfR29IE/upz4rWL9yd+pZPetR/5j2KC+jt6QJ/dTnxWsAW 9Rv2a8l/+D/41/E/E9IFY7qgfFl4gKN+zXkv/wAH/wAa/ifiekCsd1QPiy8AUH9HX0gzu6nP itYvvL366zX3qH/DjYoP6OvpBnd1OfFaxfmXv11mvvUP+HGwBQf0dvSBP7qc+K1jPlc9H3kz 7qX4UfGPo7ekCf3U58VrGfK56PvJn3Uvwo+ALdyj+4X9lnf/AEsVF9In0gwO6m/iu4t3KP7h f2Wd/wDSxUP0ifSBA7qb+K7gC/YnpBrHdcD4svBkb0fZa7qi/CHBE9INY7rgfFl4Mjej7Lfd UX4Q4An8GDBgCAzv+wGY+65Xwixz5joPPHo/zH3XK+EWOfdK/l/rizTi1X4dA5HW3k/y33XF +EOJ/gn9eKMyjn1/KsZKdJhlMpomTg7JCLrSkqkSIhWQ0UlvxIVG5cSSwo2L5Y6P6qLWvYj+ NiXU3ItrF6erovajskT+qWPgxXPPJR+xK37MfxsHPJR+xK37MfxsVxdBpyKPdPULGwiUzyV0 Kl55PN7EuoFUDkPSFbNwFa1OoSElkBFt01tx/Drxqc8lH7ErXsx/Gwc8lH7ErXsx/GwxdA5F HsnqDd+jsP6q+rtx7a+sOX6tSatzlPKbdX2dfD8dPrvxxtOU5pysxqmRHvsR3Y4Cipp0uE2R KvC97tDbj61/uR+eSj9iVv2Y/jYOeSj9iVr2Y/jYYugcij3T1DapnkroVLzyeb2JdQKoHIef VtxwFa1OoSElkBFt01tx/Drw3N05pusyKkJHvPx2mDFVTSgtk4QqnC97ulfj6k/vR+eSj9iV r2Y/jYOeSj9iVv2Y/jYYugcij2T1CMTKdAy15YGasDdXemSBlVBx1HmTabM0c82jQjukpDuq KJdV0cEJBNQ06blenU2tL5RI9PqnLPrCcciI/NZ0gu84yrYIIKrjpqVgBC0qXBXOrVP88lH7 ErXsx/GwtvZ0oZFGOK1muGcZ+VIAmghH05Dima2cIkumohFURFQSJLrqW7F0DkUeyeoPdOrU ShyavAfDbiQVlVF55H0fcZEnFdPeAB83q3FJobkRAKqtlFUwhZEoVMyjmKFMpdPqgHO5TBlH U5HmYyBKRoR3GmFbV01bWwa0S6IOpVIVX3l52yvPlPPTqXmeSJf0LZPNBya7gOltmDyGl3Gm y4kunQiDpHhjXh5ryvBEGmYWbjjJKWW5HfktPA65uq8CrrdVR0n0ugoqVump8cMXQRyaPZPU GKl1Zl/JVLqdMYiuwMvAL7LrlSRURkYrgKj220ZC8IHcm0GyKQ2MuI4kG8xrFzJJkSqNKGoO 05oZEFh4XnxVptx+4NoKa2tTps7uqyuoIIKfawoRs4ZWixUjjSsyEAnF2lLk12mozqOssjZz iAlfiVzVCW5LwVNh7PmWpFVcnOUrMnnDV0mWzYAUfVrY3kIXUMT2uhwJBTrRNXSwxdA5NHsn qGjkGnZcyhX4sykJKnyZkg6VJcaqcd+KyKo05uAehsjTUbIdSWIlHiSgh3FFpzUKVUX2jNTn SEkOIapZCRptqw8OrS2PXfiq/wBWK2pXlOolKaf/AJtzBKfku70iQ+MbW6ekQRVQHBFLAAD0 RT7N1uqqqyPPJR+xK17MfxsMXQOTR7J6ht5N8lVDyPV3qlTJdRdfdjlHIZLgEOlSErppAVvc U9f44MxeSqhZlo9Epk2XUG2KNH2I5MuAhEOkBudwVFWzadSJ68anPJR+xK17MfxsHPJR+xK1 7MfxsMXQTyKPdPUG6n5dh0z6p2XHyWlwCgMayRdTa7V1KyJcvMj1WTivDqsuZy8lVDzxWGal U5dRafajjHEYzgCOlCIrrqAlvcl9f4Y1OeSj9iVr2Y/jYOeSj9iVr2Y/jYYugcij3T1B4bpz TdZkVISc3n47UcxVU0oLZOEKpwve7pX4+pP7yk01qj0aFTWDM2YbAMNk4qKSiAoKKtkRL2T8 MI/PJR+xK17MfxsHPJR+xK17MfxsMXQORR7p6hY2DFc88lH7ErXsx/Gwc8lH7ErXsx/GwxdA 5NHunqDRnj9gMx91yU/2ixz/AIa83Z9kZpirTY0NYdNIxcPeISdeUVRRRUG6AiEl+BEpWHiK XFVS/wDXjRtNbHDX1VNzsUX4faYFwYMbL9PM/A+eD54MGIAfPB88GDAB88HzwYMAHzwfPBgw AfPB88GDAB88HzwYMAHzwfPBgwAfPB88GDAB88HzwYMAHzwfPBgwAfPB88GDAB88HzwYMAY9 SY38GDFVO2mf/9=9 --T18v6CP2tlP61v66YRQ741N-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 22 20:37:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N3bN29009020; Tue, 22 Oct 2002 20:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9N3bNBp009019; Tue, 22 Oct 2002 20:37:23 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N3bI29009012 for ; Tue, 22 Oct 2002 20:37:19 -0700 (PDT) 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 g9N3bQMq001630 for ; Tue, 22 Oct 2002 20:37:26 -0700 (PDT) Received: from starfruit.itojun.org (dhcp109.iijlab.net [202.232.15.109]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12838 for ; Tue, 22 Oct 2002 21:37:16 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 42ADF7BA; Wed, 23 Oct 2002 12:36:32 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: ono@kame.net In-reply-to: itojun's message of Thu, 17 Oct 2002 10:00:18 +0900. <20021017010018.138764B25@coconut.itojun.org> 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: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt From: Jun-ichiro itojun Hagino Date: Wed, 23 Oct 2002 12:36:32 +0900 Message-Id: <20021023033632.42ADF7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I don't get the sense that we have consensus on this, because some >>people seem to think that scoped addresses are appropriate for use by >>general-purpose apps. >> >>for instance, there's really no way that an application can effectively use >>a scoped address in a referral to another host, since the app has no idea >>whether the host that uses the referral has access to the same scope as >>the party providing the referral. name-to-address mapping is only one >>instance of this problem. another example of complication due to the scoped address. (previous example was FTP) X uses xhost(1) to control accesses to X server. For instance, % xhost +10.1.1.1 would let X clients from 10.1.1.1 to access X server. xhost(1) itself is a X client. therefore, it can be anywhere - it can talk with X server over the net. xhost(1) transmits the address (like 10.1.1.1 above) in binary form, so 32bit for IPv4. if we simply extend it to take 128bit IPv6 address, we cannot use scoped IPv6 address, because of two reasons: (1) scope identification will be stripped off when xhost(1) transmits the address to X server (since the protocol does not pass scope identification (2) even if we extend the protocol to pass around scope ID - if the view of the scope differs between xhost(1) and X server (i.e. xhost(1) and X server are on different node), it is not possible for xhost(1) to deduce scope ID on X server. one possible solution would be to make xhost(1) transmit addresses as a string, and let X server decode it. even so, the user of xhost(1) has to know the view of the scope on the machine running X server. 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 Tue Oct 22 20:40:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N3e229009050; Tue, 22 Oct 2002 20:40:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9N3e1hb009049; Tue, 22 Oct 2002 20:40:01 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9N3dw29009042 for ; Tue, 22 Oct 2002 20:39:58 -0700 (PDT) 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 g9N3e6Mq001909 for ; Tue, 22 Oct 2002 20:40:06 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13832 for ; Tue, 22 Oct 2002 21:40:00 -0600 (MDT) 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 g9N3e9H04831 for ; Wed, 23 Oct 2002 06:40:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 23 Oct 2002 06:39:58 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Oct 2002 06:39:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Oct 2002 06:39:58 +0300 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: Node Requirements status Date: Wed, 23 Oct 2002 06:39:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FBC@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWw To: X-OriginalArrivalTime: 23 Oct 2002 03:39:58.0778 (UTC) FILETIME=[DC5671A0:01C27A45] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9N3dx29009043 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, The nodes requirement draft has a number of issus to be addressed, so I would like to send a list of open issues & then send possible resolutions to the issues in seperate mails. 1) What is the correct level of support for MLD? Should MLDv2 be supported as well? 2) MIPv6 draft suggestions for Node requirements be accepted? 3) How to suppor Site Local Addresses. 4) Some issues that have come-up during Address Scoping discussion. 5) Anything needed to be captured Address Architecture document implications 6) Default Address Selection level of support. 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? 8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? 9) Are Transition mechanisms mandatory; is support for IPv4 mandatory? 10) What level of detail is needed for MIBs in the document? 11) Requirements language (MUST/SHOULD/MAY, etc.) needs discussion. So, I will try to send out today at least suggestions on a number of the points, but please speak up as to what you would like to see the addressed in the document. 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 Wed Oct 23 04:23:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NBNe29010818; Wed, 23 Oct 2002 04:23:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NBNdQd010817; Wed, 23 Oct 2002 04:23:39 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NBNa29010810 for ; Wed, 23 Oct 2002 04:23:36 -0700 (PDT) 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 g9NBNiMq005428 for ; Wed, 23 Oct 2002 04:23:44 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23817 for ; Wed, 23 Oct 2002 05:23:39 -0600 (MDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9NBNMiZ011110 for ; Wed, 23 Oct 2002 07:23:23 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 23 Oct 2002 07:23:47 -0400 Message-ID: <3DB6878B.3060604@nc.rr.com> Date: Wed, 23 Oct 2002 07:27:07 -0400 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements status References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FBC@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, john.loughney@nokia.com wrote: > Hi all, > > The nodes requirement draft has a number of issus to be addressed, so I would > like to send a list of open issues & then send possible resolutions to the > issues in seperate mails. > > 1) What is the correct level of support for MLD? Should MLDv2 be supported as well? MLDv2 has been submitted to the IESG. Given that, MLDv2 is the correct level of support. > 2) MIPv6 draft suggestions for Node requirements be accepted? > 3) How to suppor Site Local Addresses. A node is only required to support being in 1 site. The issues with multi-sited nodes is too complex to make a mandatory feature. By supporting 1 site, the node can treat the site local addresses as globals. > 4) Some issues that have come-up during Address Scoping discussion. > 5) Anything needed to be captured Address Architecture document implications > 6) Default Address Selection level of support. > 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? Given that new layer-2 technologies will appear and future docs may/will define how IPv6 runs over those layers, I would suggest using generic text that says that if a vendor wants to support IPv6 over a particular L2, then they must implement the IPv6-over-foo spec for that L2. Then I would give a few examples (IPv6-over-ethernet, etc.). > 8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? > 9) Are Transition mechanisms mandatory; is support for IPv4 mandatory? > 10) What level of detail is needed for MIBs in the document? It would be nice if the node requirements pointed out the version independent MIBs that are in progress. But, I don't think we want to hold up this spec on those specs. > 11) Requirements language (MUST/SHOULD/MAY, etc.) needs discussion. > > So, I will try to send out today at least suggestions on a number of the points, > but please speak up as to what you would like to see the addressed in the document. It would be nice to get some more details on some of these open issues Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 04:38:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NBcO29010963; Wed, 23 Oct 2002 04:38:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NBcOwE010962; Wed, 23 Oct 2002 04:38:24 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NBcK29010955 for ; Wed, 23 Oct 2002 04:38:20 -0700 (PDT) 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 g9NBcSMq007447 for ; Wed, 23 Oct 2002 04:38:28 -0700 (PDT) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA20967 for ; Wed, 23 Oct 2002 05:38:20 -0600 (MDT) Message-ID: <001701c27a88$aca57260$5c28010a@feroz> From: "Mohammad Feroz" To: "Bound, Jim" , References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9606@tayexc13.americas.cpqcorp.net> Subject: Re: IPSec Implementaion. Date: Wed, 23 Oct 2002 17:08:13 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C27AB6.C5B6E710" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C27AB6.C5B6E710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageThank you for the clarification. I would even like to know = whether IPSec is mandatory to implement for Handheld devices. Thanks & Best Regards, - Feroz ----- Original Message -----=20 From: Bound, Jim=20 To: Mohammad Feroz ; ipng@sunroof.eng.sun.com=20 Sent: Tuesday, October 22, 2002 7:51 AM Subject: RE: IPSec Implementaion. IPsec is yes and the architecture. /jim -----Original Message----- From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in]=20 Sent: Monday, October 21, 2002 8:05 AM To: ipng@sunroof.eng.sun.com Subject: IPSec Implementaion. Hello ! Is it mandatory to implement Security Architecture for IPv6 for = HOSTS? Thanks & Best Regards, - Feroz ********************************************************* Mohammed Feroz, Networking & Communication Group, Design & Development Centre, TATA Elxsi Limited, Bangalore Phone: +91-80-8410222=20 Fax: +91-80-8410219 ********************************************************* ------=_NextPart_000_0014_01C27AB6.C5B6E710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Thank you for the clarification. I would = even like=20 to know whether IPSec is mandatory to implement for Handheld=20 devices.
 
Thanks & Best = Regards,
- Feroz
----- Original Message -----
From:=20 Bound, = Jim
To: Mohammad Feroz ; ipng@sunroof.eng.sun.com =
Sent: Tuesday, October 22, 2002 = 7:51=20 AM
Subject: RE: IPSec = Implementaion.

IPsec is yes and the=20 architecture.
 
/jim
-----Original Message-----
From: = Mohammad Feroz=20 [mailto:feroz@tataelxsi.co.in]
Sent: Monday, October 21, = 2002=20 8:05 AM
To: ipng@sunroof.eng.sun.com
= Subject:=20 IPSec Implementaion.

Hello !
 
Is it mandatory to implement Security = Architecture for IPv6 for HOSTS?
 
Thanks & Best Regards,
-=20 Feroz
 
*********************************************************=
Mohammed=20 Feroz,
Networking & Communication Group,
Design & = Development=20 Centre,
TATA Elxsi Limited, Bangalore
Phone: +91-80-8410222 =
Fax:=20 = +91-80-8410219
*******************************************************= **
------=_NextPart_000_0014_01C27AB6.C5B6E710-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 07:28:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NESx29011554; Wed, 23 Oct 2002 07:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NESwRU011553; Wed, 23 Oct 2002 07:28:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NESt29011546 for ; Wed, 23 Oct 2002 07:28:55 -0700 (PDT) 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 g9NET3PG020251 for ; Wed, 23 Oct 2002 07:29:04 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07168 for ; Wed, 23 Oct 2002 08:28:58 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AC51C41A8; Wed, 23 Oct 2002 10:28:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Oct 2002 10:28:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27AA0.85553479" Subject: RE: IPSec Implementaion. Date: Wed, 23 Oct 2002 10:28:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE965E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec Implementaion. Thread-Index: AcJ6iLIKD2/WFYjlTWaf+wChqiJGXwAFxLFw From: "Bound, Jim" To: "Mohammad Feroz" , X-OriginalArrivalTime: 23 Oct 2002 14:28:57.0449 (UTC) FILETIME=[85981D90:01C27AA0] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C27AA0.85553479 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Read the IPsec arch spec and other specs. IPsec is a MUST according to us in the IETF for ANY IPv6 implementation. =20 As an implementor I would not implement any IPv6 incantation with IPv6 because I believe to not implement all MUSTs in a spec is not wise. =20 Now if at indusrtry implementation forums or bake-offs implementors find the spec don't work they stop and come tell the IETF. For IPsec that is not the case it does work. Clearly PKI to IKE interface is a problem for vendors as that usually requires melding a 3rd party key mgmt infrastructure to your implementation. But that is not the IETFs problem per se (though they do need to hear the technical issues). =20 This does not mean an implementor cannot use alternative methods to secure devices but to be compliant with the IETF IPsec architecture any implementation MUST do it. =20 Users may or may not use our recommendations that is up to the market we have no control over that in the market. I personally support them adopting IPv6 as one critical method for securing IP layer communications. But it is not the only one that they need. =20 This is my view and you should get others views too. That is how I read the specs. =20 regards, /jim -----Original Message----- From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in]=20 Sent: Wednesday, October 23, 2002 6:38 AM To: Bound, Jim; ipng@sunroof.eng.sun.com Subject: Re: IPSec Implementaion. =09 =09 Thank you for the clarification. I would even like to know whether IPSec is mandatory to implement for Handheld devices. =20 Thanks & Best Regards, - Feroz ----- Original Message -----=20 From: Bound, Jim =20 To: Mohammad Feroz ; ipng@sunroof.eng.sun.com=20 Sent: Tuesday, October 22, 2002 7:51 AM Subject: RE: IPSec Implementaion. IPsec is yes and the architecture. =20 /jim -----Original Message----- From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in]=20 Sent: Monday, October 21, 2002 8:05 AM To: ipng@sunroof.eng.sun.com Subject: IPSec Implementaion. =09 =09 Hello ! =20 Is it mandatory to implement Security Architecture for IPv6 for HOSTS? =20 Thanks & Best Regards, - Feroz =20 =09 ********************************************************* Mohammed Feroz, Networking & Communication Group, Design & Development Centre, TATA Elxsi Limited, Bangalore Phone: +91-80-8410222=20 Fax: +91-80-8410219 =09 ********************************************************* ------_=_NextPart_001_01C27AA0.85553479 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Read=20 the IPsec arch spec and other specs.  IPsec is a MUST according to = us in=20 the IETF for ANY IPv6 implementation.
 
As an=20 implementor I would not implement any IPv6 incantation with IPv6 because = I=20 believe to not implement all MUSTs in a spec is not = wise.
 
Now if=20 at indusrtry implementation forums or bake-offs implementors find the = spec don't=20 work they stop and come tell the IETF.  For IPsec that is not the = case it=20 does work.  Clearly PKI to IKE interface is a problem for vendors = as that=20 usually requires melding a 3rd party key mgmt infrastructure to your=20 implementation.  But that is not the IETFs problem per se (though = they do=20 need to hear the technical issues).
 
This=20 does not mean an implementor cannot use alternative methods to secure = devices=20 but to be compliant with the IETF IPsec architecture any implementation = MUST do=20 it.
 
Users=20 may or may not use our recommendations that is up to the market we have = no=20 control over that in the market.  I personally support them = adopting IPv6=20 as one critical method for securing IP layer communications. =20 But it is = not the only=20 one that they need.
 
This is my view and you should get others views = too.  That is=20 how I read the specs.
 
regards,
/jim
-----Original Message-----
From: = Mohammad Feroz=20 [mailto:feroz@tataelxsi.co.in]
Sent: Wednesday, October 23, = 2002=20 6:38 AM
To: Bound, Jim; = ipng@sunroof.eng.sun.com
Subject:=20 Re: IPSec Implementaion.

Thank you for the clarification. I = would even=20 like to know whether IPSec is mandatory to implement for Handheld=20 devices.
 
Thanks & Best = Regards,
- Feroz
----- Original Message -----
From:=20 Bound, = Jim=20
To: Mohammad Feroz ; ipng@sunroof.eng.sun.com =
Sent: Tuesday, October 22, = 2002 7:51=20 AM
Subject: RE: IPSec = Implementaion.

IPsec is yes and the=20 architecture.
 
/jim
-----Original Message-----
From: = Mohammad=20 Feroz [mailto:feroz@tataelxsi.co.in]
Sent: Monday, = October 21,=20 2002 8:05 AM
To: ipng@sunroof.eng.sun.com
= Subject:=20 IPSec Implementaion.

Hello !
 
Is it mandatory to implement = Security=20 Architecture for IPv6 for HOSTS?
 
Thanks & Best Regards,
-=20 Feroz
 
*********************************************************=
Mohammed=20 Feroz,
Networking & Communication Group,
Design &=20 Development Centre,
TATA Elxsi Limited, Bangalore
Phone:=20 +91-80-8410222
Fax:=20 = +91-80-8410219
*******************************************************= **
= =00 ------_=_NextPart_001_01C27AA0.85553479-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 07:44:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NEiG29011609; Wed, 23 Oct 2002 07:44:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NEiGfT011608; Wed, 23 Oct 2002 07:44:16 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NEiD29011601 for ; Wed, 23 Oct 2002 07:44:13 -0700 (PDT) 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 g9NEiLMq010835 for ; Wed, 23 Oct 2002 07:44:21 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16889 for ; Wed, 23 Oct 2002 08:44:15 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9NEi3k02529 for ; Wed, 23 Oct 2002 10:44:03 -0400 Message-Id: <200210231444.g9NEi3k02529@cichlid.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: FWD: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Wed, 23 Oct 2002 10:43:58 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to formally request the following from the WG on this document: - I'd like to see it become a WG document (to become a BCP RFC) - I'd like for folks here to review it and post any issues they have with it - I'd like to call special attention to the following text that it includes: > In addition, experience with IPv4 has shown that it is useful to > reserve an address block for documentation purposes that will never > be assigned for actual use in a network [DOC]. Such addresses can > safely be used in documentation, without the worry that someone will > accidentally (and incorrectly) configure them on a real network and > cause traffic intended for the legitimate owner of those addresses to > be impacted. > > This document reserves the IPv6 address block XXXX::/32 for > documentation purposes. There has been some private discussion about the need for addresses for documentation, but it's probably worth discussing how much address space is needed for this purpose, and what the prefix should be (e.g., allocate out of 001/3?). the /32 length is a strawman. Thomas ------- Forwarded Message From: Internet-Drafts@ietf.org To: IETF-Announce: ; Date: Wed, 23 Oct 2002 07:36:32 -0400 Subject: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Reply-to: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Allocation Guidelines for Values in IPv6 and Related Headers Author(s) : T. Narten Filename : draft-narten-ipv6-iana-considerations-00.txt Pages : 7 Date : 2002-10-22 This document provides guidelines to IANA on the procedures for assigning values for various IPv6-related fields. This document updates and replaces the IPv6-related guidelines in RFC 2780. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narten-ipv6-iana-considerations-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-narten-ipv6-iana-considerations-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-narten-ipv6-iana-considerations-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-22143511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-narten-ipv6-iana-considerations-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-narten-ipv6-iana-considerations-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-22143511.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 08:31:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NFVc29011860; Wed, 23 Oct 2002 08:31:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NFVc6A011859; Wed, 23 Oct 2002 08:31:38 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NFVZ29011852 for ; Wed, 23 Oct 2002 08:31:35 -0700 (PDT) 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 g9NFVhMq021339 for ; Wed, 23 Oct 2002 08:31:43 -0700 (PDT) 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 IAA21056 for ; Wed, 23 Oct 2002 08:31:38 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Wed, 23 Oct 2002 08:31:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3A1@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Thread-Index: AcJ6qA+jFSLABfReSMyw13x3afxikgAACZfw From: "Michel Py" To: "Thomas Narten" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9NFVZ29011853 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > Thomas Narten wrote: > There has been some private discussion about the need > for addresses for documentation, but it's probably worth > discussing how much address space is needed for this > purpose, and what the prefix should be (e.g., allocate > out of 001/3?). the /32 length is a strawman. There is a fundamental question here, which is whether or not to consider documentation new or not-yet-implemented proposals. If the answer is yes, I have an immediate need for a /15. Let's say you want to document a new protocol comparable to 6to4; you need a /16 right off the bat. If it was my call, I would allocate 3FF8::/14 for documentation. 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 Oct 23 09:21:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NGLJ29012417; Wed, 23 Oct 2002 09:21:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NGLIVb012416; Wed, 23 Oct 2002 09:21:18 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NGLG29012409 for ; Wed, 23 Oct 2002 09:21:16 -0700 (PDT) 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 g9NGLOMq005138 for ; Wed, 23 Oct 2002 09:21:24 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25243 for ; Wed, 23 Oct 2002 09:21:20 -0700 (PDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9NGL0u03713; Wed, 23 Oct 2002 12:21:05 -0400 Message-Id: <200210231621.g9NGL0u03713@cichlid.adsl.duke.edu> To: "Michel Py" cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt In-Reply-To: Message from "Michel Py" of "Wed, 23 Oct 2002 08:31:37 PDT." <2B81403386729140A3A899A8B39B046405E3A1@server2000> Date: Wed, 23 Oct 2002 12:21:00 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Thomas Narten wrote: > > There has been some private discussion about the need > > for addresses for documentation, but it's probably worth > > discussing how much address space is needed for this > > purpose, and what the prefix should be (e.g., allocate > > out of 001/3?). the /32 length is a strawman. > There is a fundamental question here, which is whether or not to > consider documentation new or not-yet-implemented proposals. If the > answer is yes, I have an immediate need for a /15. Let's say you want to > document a new protocol comparable to 6to4; you need a /16 right off the > bat. The intent of the "documentation prefix" is not for describing new protocols. Presumably, documents defining new protocols can give examples as they see fit (in IDs), and if the ID gets published as an RFC, any addresses needed would presumably be allocated (or something). Not something we need to worry about here. The purpose of the documentation prefix is assumed to be vendors wanting to give examples in their documentation for things like sample config files. 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 Wed Oct 23 09:26:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NGQp29012458; Wed, 23 Oct 2002 09:26:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NGQo4Z012457; Wed, 23 Oct 2002 09:26:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NGQl29012450 for ; Wed, 23 Oct 2002 09:26:47 -0700 (PDT) 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 g9NGQuMq006540 for ; Wed, 23 Oct 2002 09:26:56 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06178 for ; Wed, 23 Oct 2002 10:26:50 -0600 (MDT) Received: from rdroms-w2k.cisco.com (dhcp-171-71-57-14.cisco.com [171.71.57.14]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA00678 for ; Wed, 23 Oct 2002 12:26:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20021023102943.03b076d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Oct 2002 12:26:45 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-Reply-To: <4.3.2.7.2.20021011140953.02dc3bb0@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 Based on the comments and questions about the intended use for this proposed mechanism, I suggest some clarification might be needed to explain that (if I have this correct) this mechanism: * is intended for ongoing use (not just for bootstrapping) * is intended to populate a stub resolver's list of available recursive servers only if that list is otherwise unpopulated (or, perhaps used if none of the servers in the otherwise populated list has responded?) * uses three unicast addresses to provide reliability through redundancy I found the use of the phrases "pre-configured" (section 2) and "hard-coded" (section 3) in the descriptions of this mechanism confusing when I read the next-to-last paragraph in section 2, which describes this mechanism as a "last resort". I think I understand the intention, but perhaps the other phrases (which imply something about the implementation, I think) could be re-worded for consistency reduction of confusion? I have the same confusion with the phrase "find a DNS resolver" in the abstract (which may be an artifact of previous incarnations of this document). I think the mechanism might be more accurately described as: "...specifies three reserved addresses that a node may use to communicate with DNS resolvers." What is the impact on scaling of using three reserved addresses? Is this mechanism suitable for sites that want to use more than 3 recursive servers? Item (b) in section 4 includes the following reason for choosing a site-local address: "...making sure that such queries are first sent to a DNS resolver within the site perimeter increase their likelyhood of success". I infer from this text that queries could go to a DNS resolver outside the site perimeter. How is that possible if the queries have a site-local destination address? In section 5.1, what is the significance of the "full flavor general purpose DNS resolver" and "a large number of nodes" in the example? Section 5.2 points out one of the drawbacks in using site-local addresses (that should be pointed out in section 4): this mechanism won't work in a site that has no recursive resolvers. The proposed solution assumes that the site boundary between the ISP and the customer goes through the customer CPE. Suppose the boundary is in the ISP PE or on one of the links between the ISP PE and the customer site? In section 5.3, why would the CPE not pass along the address of the ISP recursive resolver to customer DHCP clients, so those clients contact the ISP resolver directly? (I see where this alternative is mentioned in the closing sentence in section 5.3). (Philosophical/soapbox) I don't agree with the third paragraph in section 1. Common practice for hosts using IPv4 is to use DHCP, which also does not require that the user perform any manual configuration. If this doc is going to contrast the proposed auto-configuration mechanism with other available mechanisms, it should make that contrast with other auto-configuration mechanisms rather than the manual configuration straw-person. (Philosophical/soapbox) The intended usage scenarios are weakly described in the last paragraph of section 1. What does "local resources available on the network to autoconfigure" mean? Isn't an SLP service or a DHCP service such a local resource? Why are cellular networks specifically called out? Why not other scenarios that exhibit mobility and transience, such as WLAN "hotspots" (Philosophical/soapbox) I'm concerned about control and interoperability of this mechanism; specifically, are there cases in which a host might rely on this mechanism when some other DNS resolvers might be available? Is this mechanism controlled or otherwise affected by the 'O' bit; for example, if the 'O' bit is set, should this mechanism not be used? (Philosophical/soapbox) Others have raised, and I will chime in on, the issue of balancing complexity in the host versus complexity in the network. The section on injection of routes glosses over the complexity of solutions b, c and d. How many different routing protocols must be supported to "run a routing protocol" or developed to use "an 'announcement' protocol"? In practice, I think option (a) is the only viable option. Nits: The document would benefit from a pass through a spell-checker. "Customer CPE (Customer Provided Equipment)" is redundant. The latest DHCPv6 draft is rev -27 (as of today or tomorrow), and the latest DHCPv6 prefix delegation draft is rev -01. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 10:01:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NH1h29012631; Wed, 23 Oct 2002 10:01:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NH1hR2012630; Wed, 23 Oct 2002 10:01:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NH1d29012623 for ; Wed, 23 Oct 2002 10:01:39 -0700 (PDT) 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 g9NH1mPG028050 for ; Wed, 23 Oct 2002 10:01:48 -0700 (PDT) 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 KAA23592 for ; Wed, 23 Oct 2002 10:01:42 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Wed, 23 Oct 2002 10:01:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3A3@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Thread-Index: AcJ6sFpN+pAec34fT8ezDUDXnvL7LQABNvuw 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 g9NH1e29012624 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > The purpose of the documentation prefix is assumed to > be vendors wanting to give examples in their documentation > for things like sample config files. Then a /32 is not enough, IMHO. A /32 is the size currently allocated to LIRs; imagine a sample BGP config that involves three LIRs, you would need at least three /32s. A /30 would be what I consider the bare minimum in this case. 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 Oct 23 10:10:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHAm29012687; Wed, 23 Oct 2002 10:10:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NHAlVq012686; Wed, 23 Oct 2002 10:10:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHAi29012679 for ; Wed, 23 Oct 2002 10:10:44 -0700 (PDT) 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 g9NHAqPG000945 for ; Wed, 23 Oct 2002 10:10:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18184 for ; Wed, 23 Oct 2002 11:10:46 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NHAcL02099; Wed, 23 Oct 2002 20:10:38 +0300 Date: Wed, 23 Oct 2002 20:10:37 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: Michel Py , Subject: Re: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt In-Reply-To: <200210231621.g9NGL0u03713@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 23 Oct 2002, Thomas Narten wrote: > The purpose of the documentation prefix is assumed to be vendors > wanting to give examples in their documentation for things like sample > config files. Was there something wrong in 3FFE:FF::/24? I guess some want it allocated directly from IANA.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 10:22:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHME29012739; Wed, 23 Oct 2002 10:22:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NHMEX6012738; Wed, 23 Oct 2002 10:22:14 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHMA29012731 for ; Wed, 23 Oct 2002 10:22:10 -0700 (PDT) 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 g9NHMJMq023280 for ; Wed, 23 Oct 2002 10:22:19 -0700 (PDT) Received: from webbox24.server-home.net (webbox24.server-home.net [62.208.70.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27560 for ; Wed, 23 Oct 2002 11:22:08 -0600 (MDT) Received: from nbsteuernagel (unknown [62.26.245.174]) by webbox24.server-home.net (Postfix) with ESMTP id 26E8A4A8B7; Wed, 23 Oct 2002 19:22:05 +0200 (CEST) From: "Kai Steuernagel" To: "Thomas Narten" , Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Wed, 23 Oct 2002 19:21:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200210231444.g9NEi3k02529@cichlid.adsl.duke.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, In general I like the idea since I'd run into this problem before (solved by choosen private address space - but didn't helped when talking/writing about NAT :-( ) I just like to ask if it would make sense to reserve an address (prefix) out of EACH 1/8th identified block even if today unassigned (as in RFC2373). - This could be unified in prefix length and value e.g. (thanks to Michael: 3FF8::/14; 5FF8::/14; 7FF8::/14; 9FF8::/14; BFF8::/14; DFF8::/14). No matter what the other unnasigned blocks will be - it could be easier to define it as of today. Just a thought. BTW: You refered to the draft "draft-iana-special-ipv4-05.txt" which is RFC3330 as of September this year. Regards Kai -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Thomas Narten Sent: Wednesday, October 23, 2002 4:44 PM To: ipng@sunroof.eng.sun.com Subject: FWD: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt I'd like to formally request the following from the WG on this document: - I'd like to see it become a WG document (to become a BCP RFC) - I'd like for folks here to review it and post any issues they have with it - I'd like to call special attention to the following text that it includes: > In addition, experience with IPv4 has shown that it is useful to > reserve an address block for documentation purposes that will never > be assigned for actual use in a network [DOC]. Such addresses can > safely be used in documentation, without the worry that someone will > accidentally (and incorrectly) configure them on a real network and > cause traffic intended for the legitimate owner of those addresses to > be impacted. > > This document reserves the IPv6 address block XXXX::/32 for > documentation purposes. There has been some private discussion about the need for addresses for documentation, but it's probably worth discussing how much address space is needed for this purpose, and what the prefix should be (e.g., allocate out of 001/3?). the /32 length is a strawman. Thomas ------- Forwarded Message From: Internet-Drafts@ietf.org To: IETF-Announce: ; Date: Wed, 23 Oct 2002 07:36:32 -0400 Subject: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Reply-to: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Allocation Guidelines for Values in IPv6 and Related Headers Author(s) : T. Narten Filename : draft-narten-ipv6-iana-considerations-00.txt Pages : 7 Date : 2002-10-22 This document provides guidelines to IANA on the procedures for assigning values for various IPv6-related fields. This document updates and replaces the IPv6-related guidelines in RFC 2780. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narten-ipv6-iana-considerations-00 .txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-narten-ipv6-iana-considerations-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-narten-ipv6-iana-considerations-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-22143511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-narten-ipv6-iana-considerations-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-narten-ipv6-iana-considerations-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-22143511.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 23 10:50:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHoB29013015; Wed, 23 Oct 2002 10:50:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NHoBqf013014; Wed, 23 Oct 2002 10:50:11 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NHo829013007 for ; Wed, 23 Oct 2002 10:50:08 -0700 (PDT) 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 g9NHoGMq002353 for ; Wed, 23 Oct 2002 10:50:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09970 for ; Wed, 23 Oct 2002 11:50:10 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NHnpJ02461; Wed, 23 Oct 2002 20:49:51 +0300 Date: Wed, 23 Oct 2002 20:49:50 +0300 (EEST) From: Pekka Savola To: Kai Steuernagel cc: Thomas Narten , Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.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 Wed, 23 Oct 2002, Kai Steuernagel wrote: > I just like to ask if it would make sense to reserve an address (prefix) out > of EACH 1/8th identified block even if today unassigned (as in RFC2373). - > This could be unified in prefix length and value e.g. (thanks to Michael: > 3FF8::/14; 5FF8::/14; 7FF8::/14; 9FF8::/14; BFF8::/14; DFF8::/14). No > matter what the other unnasigned blocks will be - it could be easier to > define it as of today. Just a thought. No, this doesn't make any sense at all, IMO. Those other 1/8th's are supposed to be _unassigned_ for now. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 12:25:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NJPq29013984; Wed, 23 Oct 2002 12:25:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9NJPq58013983; Wed, 23 Oct 2002 12:25:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9NJPn29013976 for ; Wed, 23 Oct 2002 12:25:49 -0700 (PDT) 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 g9NJPvMq007038 for ; Wed, 23 Oct 2002 12:25:57 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16021 for ; Wed, 23 Oct 2002 13:25:52 -0600 (MDT) Received: from classic.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g9NJgvj63008; Wed, 23 Oct 2002 15:42:57 -0400 (EDT) Date: Wed, 23 Oct 2002 15:22:07 -0400 From: Marc Blanchet To: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: FWD: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Message-ID: <58890000.1035400927@classic.viagenie.qc.ca> In-Reply-To: <200210231444.g9NEi3k02529@cichlid.adsl.duke.edu> References: <200210231444.g9NEi3k02529@cichlid.adsl.duke.edu> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9NJPn29013977 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -- mercredi, octobre 23, 2002 10:43:58 -0400 Thomas Narten wrote/a écrit: > I'd like to formally request the following from the WG on this > document: > > - I'd like to see it become a WG document (to become a BCP RFC) > > - I'd like for folks here to review it and post any issues they have > with it > > - I'd like to call special attention to the following text that it > includes: > >> In addition, experience with IPv4 has shown that it is useful to >> reserve an address block for documentation purposes that will never >> be assigned for actual use in a network [DOC]. Such addresses can >> safely be used in documentation, without the worry that someone will >> accidentally (and incorrectly) configure them on a real network and >> cause traffic intended for the legitimate owner of those addresses to >> be impacted. >> >> This document reserves the IPv6 address block XXXX::/32 for >> documentation purposes. > > There has been some private discussion about the need for addresses > for documentation, but it's probably worth discussing how much address > space is needed for this purpose, and what the prefix should be (e.g., > allocate out of 001/3?). the /32 length is a strawman. > - great to see that the proposal I made on address space for documentation is surviving! - I would propose that at least the space reserved is in well known boundaries: /16, /24, /32. - 3fff::/16 is for me the best: it is large, but simple and would cover most cases needed. - if not agreeable (too large), then /24. which would have room for aggregates in bgp routing. Marc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 17:01:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O01L29014985; Wed, 23 Oct 2002 17:01:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9O01LBf014984; Wed, 23 Oct 2002 17:01:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O01H29014977 for ; Wed, 23 Oct 2002 17:01:17 -0700 (PDT) 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 g9O01PbB005489 for ; Wed, 23 Oct 2002 17:01:25 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20825 for ; Wed, 23 Oct 2002 18:01:17 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id BFBB5146E4; Thu, 24 Oct 2002 10:01:09 +1000 (EST) Date: Thu, 24 Oct 2002 10:01:08 +1000 From: "Nick 'Sharkey' Moore" To: Sowmini Varadhan Cc: ipng@sunroof.eng.sun.com Subject: Re: Optimistic DAD draft ... Message-ID: <20021024100106.A10072@dwerryhouse.com.au> References: <200210221422.g9MEMsF3006348@quasimodo.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200210221422.g9MEMsF3006348@quasimodo.east.sun.com>; from sowmini@quasimodo.east.sun.com on Tue, Oct 22, 2002 at 10:22:54AM -0400 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 22, 2002 at 10:22:54AM -0400, Sowmini Varadhan wrote: > > I think this was discussed in the past: check out the thread with the > subject "ND- processing neighbor advertisements" in > ftp://playground.sun.com/pub/ipng/mail-archive/ipng.199912 Hmmm. Interesting, and opens rather a can of worms. By the way, linux-2.4.18/net/core/neighbour.c:neigh_update() seems (at a quick glance) to go with the "don't do anything if override = 0" interpretation, but then that's a whole _different_ can of worms! Most folks back in 1999 seem to have gone with the REACHABLE->STALE interpretation though ... unless there's a canonical 2461bis which fixes this problem I'm going to interpret it as a MAY, eg nodes may or may not reset the entry. Thanks everyone for your comments. I'm going to fix the draft up a bit for -01, I think getting some kind of Optimistic DAD standardized is going to be essential for Mobile IPv6 to be useful ... -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 23 20:21:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O3L829015328; Wed, 23 Oct 2002 20:21:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9O3L8JY015327; Wed, 23 Oct 2002 20:21:08 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O3L429015320 for ; Wed, 23 Oct 2002 20:21:04 -0700 (PDT) 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 g9O3LCMq010154 for ; Wed, 23 Oct 2002 20:21:12 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29058 for ; Wed, 23 Oct 2002 21:21:07 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4G0093PUN6GL@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 23 Oct 2002 21:21:07 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4G000QQUN4EB@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 23 Oct 2002 21:21:06 -0600 (MDT) Date: Wed, 23 Oct 2002 20:21:23 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt In-reply-to: <2B81403386729140A3A899A8B39B046405E3A1@server2000> To: Michel Py Cc: Thomas Narten , ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, October 23, 2002, at 08:31 AM, Michel Py wrote: > Thomas, > >> Thomas Narten wrote: >> There has been some private discussion about the need >> for addresses for documentation, but it's probably worth >> discussing how much address space is needed for this >> purpose, and what the prefix should be (e.g., allocate >> out of 001/3?). the /32 length is a strawman. > > There is a fundamental question here, which is whether or not to > consider documentation new or not-yet-implemented proposals. If the > answer is yes, I have an immediate need for a /15. Let's say you want > to > document a new protocol comparable to 6to4; you need a /16 right off > the > bat. > > If it was my call, I would allocate 3FF8::/14 for documentation. And if you wanted to document a complete different address scheme, you would need at least half the entire address space.... I do not think this is a valid argument. One need to reserve a portion of the address space to describe example scenarios in product documentation. For that, the address space need to be large enough to accommodate a decent size network. I think a /32 is plenty and I support Thomas proposal... - 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 Wed Oct 23 20:28:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O3SA29015375; Wed, 23 Oct 2002 20:28:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9O3SAVN015374; Wed, 23 Oct 2002 20:28:10 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9O3S629015367 for ; Wed, 23 Oct 2002 20:28:06 -0700 (PDT) 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 g9O3SEMq011020 for ; Wed, 23 Oct 2002 20:28:14 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01607 for ; Wed, 23 Oct 2002 21:28:09 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4G00GDVUYW8G@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 23 Oct 2002 21:28:09 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4G00911UYUE4@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 23 Oct 2002 21:28:08 -0600 (MDT) Date: Wed, 23 Oct 2002 20:28:25 -0700 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" In-reply-to: <4.3.2.7.2.20021023102943.03b076d0@funnel.cisco.com> To: Ralph Droms Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for all those comments. I will use them and others to generate a -07 revision asap. - Alain. On Wednesday, October 23, 2002, at 09:26 AM, Ralph Droms wrote: > Based on the comments and questions about the intended use for this > proposed mechanism, I suggest some clarification might be needed to > explain that (if I have this correct) this mechanism: > > * is intended for ongoing use (not > just for bootstrapping) > * is intended to populate a stub resolver's list > of available recursive servers only if that list > is otherwise unpopulated (or, perhaps used if none > of the servers in the otherwise populated list > has responded?) > * uses three unicast addresses to provide reliability > through redundancy > > I found the use of the phrases "pre-configured" (section 2) and > "hard-coded" (section 3) in the descriptions of this mechanism > confusing when I read the next-to-last paragraph in section 2, which > describes this mechanism as a "last resort". I think I understand the > intention, but perhaps the other phrases (which imply something about > the implementation, I think) could be re-worded for consistency > reduction of confusion? > > I have the same confusion with the phrase "find a DNS resolver" in the > abstract (which may be an artifact of previous incarnations of this > document). I think the mechanism might be more accurately described > as: "...specifies three reserved addresses that a node may use to > communicate with DNS resolvers." > > What is the impact on scaling of using three reserved addresses? Is > this mechanism suitable for sites that want to use more than 3 > recursive servers? > > Item (b) in section 4 includes the following reason for choosing a > site-local address: > > "...making sure that such queries are first sent to a DNS > resolver within the site perimeter increase their likelyhood > of success". > > I infer from this text that queries could go to a DNS > resolver outside the site perimeter. How is that possible > if the queries have a site-local destination address? > > In section 5.1, what is the significance of the "full flavor general > purpose DNS resolver" and "a large number of nodes" in the example? > > Section 5.2 points out one of the drawbacks in using site-local > addresses (that should be pointed out in section 4): this mechanism > won't work in a site that has no recursive resolvers. The proposed > solution assumes that the site boundary between the ISP and the > customer goes through the customer CPE. Suppose the boundary is in > the ISP PE or on one of the links between the ISP PE and the customer > site? > > In section 5.3, why would the CPE not pass along the address of the > ISP recursive resolver to customer DHCP clients, so those clients > contact the ISP resolver directly? (I see where this alternative is > mentioned in the closing sentence in section 5.3). > > (Philosophical/soapbox) I don't agree with the third paragraph in > section 1. Common practice for hosts using IPv4 is to use DHCP, which > also does not require that the user perform any manual configuration. > If this doc is going to contrast the proposed auto-configuration > mechanism with other available mechanisms, it should make that > contrast with other auto-configuration mechanisms rather than the > manual configuration straw-person. > > (Philosophical/soapbox) The intended usage scenarios are weakly > described in the last paragraph of section 1. What does "local > resources available on the network to autoconfigure" mean? Isn't an > SLP service or a DHCP service such a local resource? Why are cellular > networks specifically called out? Why not other scenarios that > exhibit mobility and transience, such as WLAN "hotspots" > > (Philosophical/soapbox) I'm concerned about control and > interoperability of this mechanism; specifically, are there cases in > which a host might rely on this mechanism when some other DNS > resolvers might be available? Is this mechanism controlled or > otherwise affected by the 'O' bit; for example, if the 'O' bit is set, > should this mechanism not be used? > > (Philosophical/soapbox) Others have raised, and I will chime in on, > the issue of balancing complexity in the host versus complexity in the > network. The section on injection of routes glosses over the > complexity of solutions b, c and d. How many different routing > protocols must be supported to "run a routing protocol" or developed > to use "an 'announcement' protocol"? In practice, I think option (a) > is the only viable option. > > Nits: > > The document would benefit from a pass through a spell-checker. > > "Customer CPE (Customer Provided Equipment)" is redundant. > > The latest DHCPv6 draft is rev -27 (as of today or tomorrow), and the > latest DHCPv6 prefix delegation draft is rev -01. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 24 03:54:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OAs229016560; Thu, 24 Oct 2002 03:54:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OAs1HB016559; Thu, 24 Oct 2002 03:54:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OArw29016552 for ; Thu, 24 Oct 2002 03:53:58 -0700 (PDT) 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 g9OAs6bB015237 for ; Thu, 24 Oct 2002 03:54:06 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24545 for ; Thu, 24 Oct 2002 04:54:00 -0600 (MDT) 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 g9OArcw00047 for ; Thu, 24 Oct 2002 13:53:38 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 24 Oct 2002 13:53:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 13:53:59 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node Requirements - issue 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 24 Oct 2002 13:53:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5985@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwAEGrirA= To: , X-OriginalArrivalTime: 24 Oct 2002 10:53:59.0288 (UTC) FILETIME=[A81AAF80:01C27B4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9OArx29016553 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Delving a bit deeper into this: > 1) What is the correct level of support for MLD? > Should MLDv2 be supported as well? I have gotten comments stating: MLD should be Conditionally Mandatory based on the use of multicast "applications" on the node (where the multicast group is of scope 2 or higher, except the all-nodes group). A primary IPv6 multicast application is Neighbor Discovery (all those solicited-node mcast addresses must be joined). and from Brian Haberman: MLDv2 has been submitted to the IESG. Given that, MLDv2 is the correct level of support. So I think I should add text conformant to the above. 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 Oct 24 04:10:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBAm29016648; Thu, 24 Oct 2002 04:10:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OBAmaS016647; Thu, 24 Oct 2002 04:10:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBAj29016640 for ; Thu, 24 Oct 2002 04:10:45 -0700 (PDT) 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 g9OBArbB017667 for ; Thu, 24 Oct 2002 04:10:53 -0700 (PDT) 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 FAA07871 for ; Thu, 24 Oct 2002 05:10:47 -0600 (MDT) 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 g9OBAPw14797 for ; Thu, 24 Oct 2002 14:10:25 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 24 Oct 2002 14:10:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 14:10:44 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node Requirements issue 2 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 24 Oct 2002 14:10:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FC6@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwAEHBwSA= To: , X-OriginalArrivalTime: 24 Oct 2002 11:10:44.0156 (UTC) FILETIME=[FF0D5FC0:01C27B4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9OBAj29016641 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > 2) MIPv6 draft suggestions for Node requirements be accepted? I've listed below the comments from Mobile IPv6 lastest draft. I think they breakdown as: All Nodes MUST be able to process Home Address Optional. All Nodes MUST be able to send a Binding Error message. All Nodes MUST be able to participate in Return Routability All nodes SHOULD be able to participate in Route Optimization (see MIPv6 spec) All Nodes MAY be a mobile node (refer to MIPv6 spec). All routers MAY be a home agent (refer to MIPv6 spec). Does the WG feel comfortable with this? Detailed quotes from the MIPv6 spec in progress: http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt - General Requirements for All IPv6 Nodes Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. The following requirements are necessary for every IPv6 node (whether host or router, whether mobile or stationary), since otherwise communications may be impossible: - The node MUST be able to process a Home Address option in any IPv6 packet, and validate the option using an IPsec SA, as described in Section 9.2.2. - The node MUST be able to send a Binding Error message as described in Section 9.4.6. - Route Optimization Requirements for All IPv6 Nodes The ability of a correspondent node to participate in route optimization is essential for the efficient operation of the IPv6 Internet, beneficial for robustness and reduction of jitter and latency, and necessary to avoid congestion in the home network. The following requirements apply to all correspondent nodes that support route optimization: - The node MUST be able validate a Home Address option using an existing Binding Cache entry, as described in Section 9.2.2. - The node MUST be able to participate in a return routability procedure (Section 9.3). - The node MUST be able to process Binding Update messages (Section 9.4). - The node MUST be able to return a Binding Acknowledgement (Section 6.1.8). - The node MUST be able to maintain a Binding Cache of the bindings received in accepted Binding Updates, as described in Sections 9.1 and 9.5. - The node MUST be able to insert a Routing Header type 2 into packets to be sent to a mobile node, as described in Section 9.6. - Unless the correspondent node is also acting as a mobile node, it MUST ignore Type 2 Routing Headers and drop all packets that it has received with such headers. - The node SHOULD be able to interpret ICMP messages as described in Section 9.7. - Requirements for All IPv6 Routers All IPv6 routers, even those not serving as a home agent for Mobile IPv6, have an effect on how well mobile nodes can communicate: - Every IPv6 router SHOULD be able to send an Advertisement Interval option (Section 7.3) in each of its Router Advertisements [12], to aid movement detection by mobile nodes (as in Section 11.5.1). The use of this option in Router Advertisements MUST be configurable. - Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. The use of this faster rate MUST be configurable. - Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2). - Filtering routers SHOULD support different rules for Type 0 and Type 2 Routing Headers (see Section 6.4) so that filtering of source routed packets (Type 0) will not necessarily limit MIPv6 traffic which is delivered via Type 2 Routing Headers. - Requirements for IPv6 Home Agents In order for a mobile node to operate correctly while away from home, at least one IPv6 router on the mobile node's home link must function as a home agent for the mobile node. The following additional requirements apply to all IPv6 routers that serve as a home agent: - Every home agent MUST be able to maintain an entry in its Binding Cache for each mobile node for which it is serving as the home agent (Sections 10.1 and 10.3). - Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery [12]) addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section 10.5). - Every home agent MUST be able to encapsulate [15] such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section 10.6). - Every home agent MUST support decapsulating [15] reverse tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node (Section 10.7). - Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update received with the Acknowledge (A) bit set (Section 10.3). - Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in Section 4.5. - Every home agent MUST be able to accept packets addressed to the Mobile IPv6 Home-Agents anycast address for the subnet on which it is serving as a home agent [16], and MUST be able to participate in dynamic home agent address discovery (Section 10.10). - Every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends (Section 7.4). - Every home agent SHOULD support sending ICMP Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Solicitations (Section 6.7). This behavior MUST be configurable, so that home agents can be configured to avoid sending such Prefix Advertisements according to the needs of the network administration in the home domain. - Every home agent MUST support IPSec ESP for protection of packets belonging to the return routability procedure (Section 10.8). 8.5. Requirements for IPv6 Mobile Nodes Finally, the following requirements apply to all IPv6 nodes capable of functioning as mobile nodes: - The node MUST be able to perform IPv6 encapsulation and decapsulation [15]. - The node MUST support the return routability procedure (Section 5.2.5). - The node MUST be able to send Binding Updates, as specified in Sections 11.7.1 and 11.7.2. - The node MUST be able to receive and process Binding Acknowledgements, as specified in Section 11.7.3. - The node MUST maintain a Binding Update List (Section 11.1). - The node MUST support receiving a Binding Refresh Request (Section 6.1.2), by responding with a Binding Update. - The node MUST support sending packets containing a Home Address option (Section 11.3.1). - The node MUST maintain a Home Agents List, as described in Section 4.5. - The node MUST support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. - The node SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 11.4.1. - The node MUST be able to process Type 2 Routing Header as defined in Sections 6.4 and 11.3.3. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 04:14:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBEh29016681; Thu, 24 Oct 2002 04:14:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OBEhLB016680; Thu, 24 Oct 2002 04:14:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBEe29016673 for ; Thu, 24 Oct 2002 04:14:40 -0700 (PDT) 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 g9OBEmbB018145 for ; Thu, 24 Oct 2002 04:14:48 -0700 (PDT) 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 EAA29312 for ; Thu, 24 Oct 2002 04:14:42 -0700 (PDT) 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 g9OBErH14704 for ; Thu, 24 Oct 2002 14:14:53 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 24 Oct 2002 14:14:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 14:14:41 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node Requirements Issue 3 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 24 Oct 2002 14:14:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwAEJU50A= To: X-OriginalArrivalTime: 24 Oct 2002 11:14:41.0327 (UTC) FILETIME=[8C6ACBF0:01C27B4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9OBEe29016674 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > 3) How to support Site Local Addresses. Brian Haberman said: A node is only required to support being in 1 site. The issues with multi-sited nodes is too complex to make a mandatory feature. By supporting 1 site, the node can treat the site local addresses as globals. Bob Hinden said: Part of that was that we would add text to the Node Requirements document that nodes are only required to implement the rules specified in the default address selection document (now a Proposed Standard) and that there be no requirement that a node must be able to be part of more than one zone. So, this means that: A node MUST support Default Address Selection. A node MUST support being in 1 site; MAY support being in more than one. 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 Oct 24 04:34:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBYd29016827; Thu, 24 Oct 2002 04:34:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OBYdj5016826; Thu, 24 Oct 2002 04:34:39 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OBYa29016819 for ; Thu, 24 Oct 2002 04:34:36 -0700 (PDT) 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 g9OBYiMq023150 for ; Thu, 24 Oct 2002 04:34:44 -0700 (PDT) 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 EAA02314 for ; Thu, 24 Oct 2002 04:34:37 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9F5756A904; Thu, 24 Oct 2002 14:34:36 +0300 (EEST) Message-ID: <3DB7DA5A.30404@kolumbus.fi> Date: Thu, 24 Oct 2002 14:32:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements issue 2 References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FC6@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, unfortunately the intermediate version you referenced didn't yet include changes for the new consensus we reached on the MIPv6 list. Below you will find the current summarized situation: All nodes MUST (no requirements!) All nodes SHOULD be able to participate in Route Optimization All nodes MAY be a mobile node All routers MAY be a home agent Here's the text: 8.1. General Requirements for All IPv6 Nodes Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. There are no Mobile IPv6 specific requirements for such nodes, and standard IPv6 techniques are sufficient. 8.2. Requirements for IPv6 Nodes that Support Route Optimisation Nodes that implement route optimization are a subset of all IPv6 nodes on the Internet. The ability of a correspondent node to participate in route optimization is essential for the efficient operation of the IPv6 Internet, beneficial for robustness and reduction of jitter and latency, and necessary to avoid congestion in the home network. The following requirements apply to all correspondent nodes that support route optimization: - The node MUST be able validate a Home Address option using an existing Binding Cache entry, as described in Section 9.2.2. - The node MUST be able to participate in a return routability procedure (Section 9.3). - The node MUST be able to process Binding Update messages (Section 9.4). - The node MUST be able to return a Binding Acknowledgement (Section 6.1.8). - The node MUST be able to maintain a Binding Cache of the bindings received in accepted Binding Updates, as described in Sections 9.1 and 9.5. - The node MUST be able to insert a Routing Header type 2 into packets to be sent to a mobile node, as described in Section 9.6. - Unless the correspondent node is also acting as a mobile node, it MUST ignore Type 2 Routing Headers and drop all packets that it has received with such headers. - The node SHOULD be able to interpret ICMP messages as described in Section 9.7. 8.3. Requirements for All IPv6 Routers All IPv6 routers, even those not serving as a home agent for Mobile IPv6, have an effect on how well mobile nodes can communicate: - Every IPv6 router SHOULD be able to send an Advertisement Interval option (Section 7.3) in each of its Router Advertisements [12], to aid movement detection by mobile nodes (as in Section 11.5.1). The use of this option in Router Advertisements MUST be configurable. - Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. The use of this faster rate MUST be configurable. - Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2). - Filtering routers SHOULD support different rules for Type 0 and Type 2 Routing Headers (see Section 6.4) so that filtering of source routed packets (Type 0) will not necessarily limit MIPv6 traffic which is delivered via Type 2 Routing Headers. 8.4. Requirements for IPv6 Home Agents In order for a mobile node to operate correctly while away from home, at least one IPv6 router on the mobile node's home link must function as a home agent for the mobile node. The following additional requirements apply to all IPv6 routers that serve as a home agent: - Every home agent MUST be able to maintain an entry in its Binding Cache for each mobile node for which it is serving as the home agent (Sections 10.1 and 10.3). - Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery [12]) addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section 10.5). - Every home agent MUST be able to encapsulate [15] such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section 10.6). - Every home agent MUST support decapsulating [15] reverse tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node (Section 10.7). - Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update received with the Acknowledge (A) bit set (Section 10.3). - Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in Section 4.5. - Every home agent MUST be able to accept packets addressed to the Mobile IPv6 Home-Agents anycast address for the subnet on which it is serving as a home agent [16], and MUST be able to participate in dynamic home agent address discovery (Section 10.10). - Every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends (Section 7.4). - Every home agent SHOULD support sending ICMP Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Solicitations (Section 6.7). This behavior MUST be configurable, so that home agents can be configured to avoid sending such Prefix Advertisements according to the needs of the network administration in the home domain. - Every home agent MUST support IPsec ESP for protection of packets belonging to the return routability procedure (Section 10.8). 8.5. Requirements for IPv6 Mobile Nodes Finally, the following requirements apply to all IPv6 nodes capable of functioning as mobile nodes: - The node MUST be able to perform IPv6 encapsulation and decapsulation [15]. - The node MUST support the return routability procedure (Section 5.2.5). - The node MUST be able to send Binding Updates, as specified in Sections 11.7.1 and 11.7.2. - The node MUST be able to receive and process Binding Acknowledgements, as specified in Section 11.7.3. - The node MUST maintain a Binding Update List (Section 11.1). - The node MUST support receiving a Binding Refresh Request (Section 6.1.2), by responding with a Binding Update. - The node MUST support sending packets containing a Home Address option (Section 11.3.1). - The node MUST support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. - The node SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 11.4.1. - The node MUST be able to process Type 2 Routing Header as defined in Sections 6.4 and 11.3.3. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 05:11:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OCBo29017162; Thu, 24 Oct 2002 05:11:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OCBogb017161; Thu, 24 Oct 2002 05:11:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OCBl29017154 for ; Thu, 24 Oct 2002 05:11:47 -0700 (PDT) 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 g9OCBtMq027677 for ; Thu, 24 Oct 2002 05:11:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18863 for ; Thu, 24 Oct 2002 05:11:49 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9OCBio14929; Thu, 24 Oct 2002 15:11:44 +0300 Date: Thu, 24 Oct 2002 15:11:43 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements - issue 1 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5985@esebe004.ntc.nokia.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, 24 Oct 2002 john.loughney@nokia.com wrote: > Delving a bit deeper into this: > > > 1) What is the correct level of support for MLD? > > Should MLDv2 be supported as well? > > I have gotten comments stating: > > MLD should be Conditionally Mandatory based on the use of multicast > "applications" on the node (where the multicast group is of scope > 2 or higher, except the all-nodes group). A primary IPv6 multicast > application is Neighbor Discovery (all those solicited-node mcast > addresses must be joined). > > and from Brian Haberman: > > MLDv2 has been submitted to the IESG. Given that, MLDv2 is the > correct level of support. > > So I think I should add text conformant to the above. I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is new and much more code than MLDv1; rather like MUST for MLDv1 as above, SHOULD for overall MLDv2. Depends on how often you want to revise the doc, I guess. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 06:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODf929017429; Thu, 24 Oct 2002 06:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ODf9Fj017428; Thu, 24 Oct 2002 06:41:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODf629017421 for ; Thu, 24 Oct 2002 06:41:06 -0700 (PDT) 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 g9ODfDbB009396 for ; Thu, 24 Oct 2002 06:41:13 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04647 for ; Thu, 24 Oct 2002 06:41:07 -0700 (PDT) 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 g9ODejw17167 for ; Thu, 24 Oct 2002 16:40:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Oct 2002 16:41:06 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 16:41:04 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 16:41:04 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node Requirements issue 2 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 24 Oct 2002 16:41:03 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5999@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements issue 2 Thread-Index: AcJ7UVWCWR4hoNy3T5ir7mHdAkmXJAAEZsMA To: Cc: X-OriginalArrivalTime: 24 Oct 2002 13:41:04.0329 (UTC) FILETIME=[FF7E8B90:01C27B62] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ODf629017422 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, > John, unfortunately the intermediate version you referenced > didn't yet include changes for the new consensus we reached on > the MIPv6 list. Below you will find the current summarized > situation: > > All nodes MUST (no requirements!) > All nodes SHOULD be able to participate in Route Optimization > All nodes MAY be a mobile node > All routers MAY be a home agent This sounds like it will be OK, then. 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 Oct 24 06:42:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODg929017440; Thu, 24 Oct 2002 06:42:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ODg9Kw017439; Thu, 24 Oct 2002 06:42:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODg529017432 for ; Thu, 24 Oct 2002 06:42:05 -0700 (PDT) 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 g9ODgDbB009552 for ; Thu, 24 Oct 2002 06:42:13 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13791 for ; Thu, 24 Oct 2002 07:42:07 -0600 (MDT) 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 g9ODgIH17029 for ; Thu, 24 Oct 2002 16:42:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Oct 2002 16:42:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 16:42:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node Requirements - issue 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 24 Oct 2002 16:42:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A599A@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements - issue 1 Thread-Index: AcJ7VpTUqLE3FeW7SNiRE0V0eBeeWwADHO3w To: Cc: X-OriginalArrivalTime: 24 Oct 2002 13:42:06.0127 (UTC) FILETIME=[24542BF0:01C27B63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ODg629017433 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is > new and much more code than MLDv1; rather like MUST for MLDv1 > as above, SHOULD for overall MLDv2. I tend to agree, but I am not an expert in MLDv2, so I just want to know what will break if nodes don't impelement it. 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 Oct 24 06:56:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODud29017597; Thu, 24 Oct 2002 06:56:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ODudgc017596; Thu, 24 Oct 2002 06:56:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ODuZ29017589 for ; Thu, 24 Oct 2002 06:56:36 -0700 (PDT) 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 g9ODuibB012079 for ; Thu, 24 Oct 2002 06:56:44 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26436 for ; Thu, 24 Oct 2002 07:56:38 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9ODuGiZ002125; Thu, 24 Oct 2002 09:56:16 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 24 Oct 2002 09:56:14 -0400 Message-ID: <3DB7FB76.9090903@nc.rr.com> Date: Thu, 24 Oct 2002 09:53:58 -0400 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: john.loughney@nokia.com CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements - issue 1 References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A599A@esebe004.ntc.nokia.com> 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 Pekka, > > >>I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is >>new and much more code than MLDv1; rather like MUST for MLDv1 >>as above, SHOULD for overall MLDv2. > > > I tend to agree, but I am not an expert in MLDv2, so I just > want to know what will break if nodes don't impelement it. Nothing will break. New implementations that support MLDv2 can, if necessary, fall back to MLDv1 in the presence of older versions. I don't think code size should even be considered. MLDv2 is a more robust protocol that allows for newer functionality, like SSM. Another point to consider is that RFC 2710 (MLDv1) will not progress beyond Proposed Standard. If the point of this document is to tell new implementors what they should implement, then my feeiling is that the group management protocol should be MLDv2. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 07:08:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OE8V29017675; Thu, 24 Oct 2002 07:08:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OE8VRI017674; Thu, 24 Oct 2002 07:08:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OE8R29017667 for ; Thu, 24 Oct 2002 07:08:28 -0700 (PDT) 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 g9OE8ZbB014474 for ; Thu, 24 Oct 2002 07:08:36 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03605 for ; Thu, 24 Oct 2002 08:08:29 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9OE8PR16398; Thu, 24 Oct 2002 17:08:26 +0300 Date: Thu, 24 Oct 2002 17:08:25 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: john.loughney@nokia.com, Subject: Re: Node Requirements - issue 1 In-Reply-To: <3DB7FB76.9090903@nc.rr.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, 24 Oct 2002, Brian Haberman wrote: > If the point of this document is to tell new implementors what > they should implement, then my feeiling is that the group > management protocol should be MLDv2. I agree. But there is more to it than just new implementations. To be fair.. if NodeReqs is intended to take e.g. 12-18 months to finish (usual with IETF, unfortunately), sure, why not.. then the point is probably already moot. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 08:02:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OF2i29017917; Thu, 24 Oct 2002 08:02:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OF2inY017916; Thu, 24 Oct 2002 08:02:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OF2e29017909 for ; Thu, 24 Oct 2002 08:02:40 -0700 (PDT) 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 g9OF2mbB025014 for ; Thu, 24 Oct 2002 08:02:48 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12917 for ; Thu, 24 Oct 2002 09:02:42 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9OF2e014626; Thu, 24 Oct 2002 11:02:40 -0400 (EDT) Message-Id: <200210241502.g9OF2e014626@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 24 Oct 2002 14:14:40 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.nokia.com> Date: Thu, 24 Oct 2002 11:02:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we'd be far better off to deprecate site local addresses, as nobody has actually given a convincing case for their use. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 08:15:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OFF329018006; Thu, 24 Oct 2002 08:15:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OFF3a4018005; Thu, 24 Oct 2002 08:15:03 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OFF029017998 for ; Thu, 24 Oct 2002 08:15:00 -0700 (PDT) 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 g9OFF8Mq002953 for ; Thu, 24 Oct 2002 08:15:08 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01061 for ; Thu, 24 Oct 2002 08:15:02 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9OFEus16912; Thu, 24 Oct 2002 18:14:56 +0300 Date: Thu, 24 Oct 2002 18:14:56 +0300 (EEST) From: Pekka Savola To: Keith Moore cc: john.loughney@nokia.com, Subject: Re: Node Requirements Issue 3 In-Reply-To: <200210241502.g9OF2e014626@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 24 Oct 2002, Keith Moore wrote: > we'd be far better off to deprecate site local addresses, as nobody has > actually given a convincing case for their use. I got the same hunch too, but first they'd have to be killed from addrarch revision, I believe -- or at least some wordings softened. Site-local --> experimental ? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 08:23:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OFNd29018095; Thu, 24 Oct 2002 08:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OFNdvn018094; Thu, 24 Oct 2002 08:23:39 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OFNa29018087 for ; Thu, 24 Oct 2002 08:23:36 -0700 (PDT) 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 g9OFNiMq005000 for ; Thu, 24 Oct 2002 08:23:44 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28382 for ; Thu, 24 Oct 2002 09:23:39 -0600 (MDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-264.cisco.com [10.21.97.8]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02201 for ; Thu, 24 Oct 2002 11:23:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20021024112153.00b6a970@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Oct 2002 11:23:20 -0400 To: From: Ralph Droms Subject: Re: Node Requirements Issue 3 In-Reply-To: References: <200210241502.g9OF2e014626@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In addition, my intuition is that we don't fully understand the impact and effect of site-local addresses on, for example, router configuration, DNS, addressing architecture, etc. It would help if we had a document describing use cases and open issues that we could discuss... - Ralph At 06:14 PM 10/24/2002 +0300, Pekka Savola wrote: >On Thu, 24 Oct 2002, Keith Moore wrote: > > we'd be far better off to deprecate site local addresses, as nobody has > > actually given a convincing case for their use. > >I got the same hunch too, but first they'd have to be killed from addrarch >revision, I believe -- or at least some wordings softened. > >Site-local --> experimental ? > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 09:11:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGBm29018452; Thu, 24 Oct 2002 09:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OGBlt8018451; Thu, 24 Oct 2002 09:11:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGBi29018444 for ; Thu, 24 Oct 2002 09:11:44 -0700 (PDT) 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 g9OGBqbB012582 for ; Thu, 24 Oct 2002 09:11:52 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15591 for ; Thu, 24 Oct 2002 10:11:41 -0600 (MDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de (8.11.6/8.11.6) with ESMTP id g9OGBAp19404 for ; Thu, 24 Oct 2002 18:11:10 +0200 (MEST) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by mailgw1.fraunhofer.de (8.11.6/8.11.6) with ESMTP id g9OGB9D19398 for ; Thu, 24 Oct 2002 18:11:09 +0200 (MEST) Received: from esk.fhg.de (host3-24 [192.168.3.24]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id SAA09932 for ; Thu, 24 Oct 2002 18:11:08 +0200 (MET DST) Message-ID: <3DB81B9D.4B457FCD@esk.fhg.de> Date: Thu, 24 Oct 2002 18:11:09 +0200 From: Walter Zimmer Organization: FhG - ESK X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Unsolicitated Neighbor Advertisement on Link-Up Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! When unplugging an IPv6 node from an ethernet switchport and plugging it back into another, the host is not reachable until the switching table timeout expired (or any ARP timeout occurs). Therefore, in this respect, IPv6 is not superior to IPv4. Are there any negative consequences if an IPv6 node sends out an unsolicitated neighbor advertisement after the link comes up again? It might choose a random delay (e.g. up to 1 sec), but I think this would be beneficial in hiding the ugly details of switching tables from the user. Or did I miss it and it is already included in some IPv6 spec? I looked into NDP (RFC 2461) and IPv6 over Ethernet (RFC 2464). Thanks for any info on this topic, Walter -- Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK) Walter Zimmer Hansastraße 32 Dipl.-Inf. D-80686 München Telefon: +49(0)89-547088-344 walter.zimmer@esk.fraunhofer.de Telefax: +49(0)89-547088-221 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 09:22:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGMq29018560; Thu, 24 Oct 2002 09:22:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OGMqvX018559; Thu, 24 Oct 2002 09:22:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGMm29018552 for ; Thu, 24 Oct 2002 09:22:48 -0700 (PDT) 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 g9OGMubB015683 for ; Thu, 24 Oct 2002 09:22:56 -0700 (PDT) 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 JAA27487 for ; Thu, 24 Oct 2002 09:22:51 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Thu, 24 Oct 2002 08:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3AF@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Thread-Index: AcJ6sFpN+pAec34fT8ezDUDXnvL7LQAw/akg 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 g9OGMn29018553 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > Thomas Narten wrote: > The intent of the "documentation prefix" is not for > describing new protocols. Presumably, documents defining > new protocols can give examples as they see fit (in IDs), > and if the ID gets published as an RFC, any addresses > needed would presumably be allocated (or something). Not > something we need to worry about here. I will point out that there is a fine line between hijacking a prefix for development/documentation purposes and hijacking it on the 6bone or even on a production network, and we have seen in the past that this line could be crossed. The point I was trying to make is that the documentation prefix would be a prime candidate for the bogon list, and if it's big enough it would also be what new protocol developers would use in the initial phase, and possibly avoid some hijacking. That being said and as I mentioned before something slightly bigger than a /32 would be ok, but I would rather have a /24 as Marc mentioned. 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 Oct 24 09:51:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGpJ29018732; Thu, 24 Oct 2002 09:51:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OGpIND018731; Thu, 24 Oct 2002 09:51:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OGpF29018724 for ; Thu, 24 Oct 2002 09:51:15 -0700 (PDT) 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 g9OGpNbB023849 for ; Thu, 24 Oct 2002 09:51:23 -0700 (PDT) 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 KAA11947 for ; Thu, 24 Oct 2002 10:51:14 -0600 (MDT) 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 JAA18979 for ; Thu, 24 Oct 2002 09:51:03 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9OGp2V01509 for ; Thu, 24 Oct 2002 09:51:02 -0700 X-mProtect: <200210241651> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdH2Knf4; Thu, 24 Oct 2002 09:51:00 PDT Message-ID: <3DB8259E.4080204@iprg.nokia.com> Date: Thu, 24 Oct 2002 09:53:50 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: FWD: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This question came up during one of the ISATAP draft revisions. We were intending to adopt Marc's proposed reserved address space for documentation, but couldn't find a proper reference. I favor the /16 example - it should be large enough to cover unanticipated future use cases. Fred ftemplin@iprg.nokia.com Marc Blanchet wrote: > > -- mercredi, octobre 23, 2002 10:43:58 -0400 Thomas Narten > wrote/a icrit: > > >>I'd like to formally request the following from the WG on this >>document: >> >> - I'd like to see it become a WG document (to become a BCP RFC) >> >> - I'd like for folks here to review it and post any issues they have >> with it >> >> - I'd like to call special attention to the following text that it >> includes: >> >> >>> In addition, experience with IPv4 has shown that it is useful to >>> reserve an address block for documentation purposes that will never >>> be assigned for actual use in a network [DOC]. Such addresses can >>> safely be used in documentation, without the worry that someone will >>> accidentally (and incorrectly) configure them on a real network and >>> cause traffic intended for the legitimate owner of those addresses to >>> be impacted. >>> >>> This document reserves the IPv6 address block XXXX::/32 for >>> documentation purposes. >> >>There has been some private discussion about the need for addresses >>for documentation, but it's probably worth discussing how much address >>space is needed for this purpose, and what the prefix should be (e.g., >>allocate out of 001/3?). the /32 length is a strawman. >> > > > - great to see that the proposal I made on address space for documentation > is surviving! > - I would propose that at least the space reserved is in well known > boundaries: /16, /24, /32. > - 3fff::/16 is for me the best: it is large, but simple and would cover > most cases needed. > - if not agreeable (too large), then /24. which would have room for > aggregates in bgp routing. > > Marc. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 24 10:01:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OH1T29018803; Thu, 24 Oct 2002 10:01:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OH1TV4018802; Thu, 24 Oct 2002 10:01:29 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OH1P29018795 for ; Thu, 24 Oct 2002 10:01:26 -0700 (PDT) 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 g9OH1YMq003879 for ; Thu, 24 Oct 2002 10:01:34 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01749 for ; Thu, 24 Oct 2002 11:01:28 -0600 (MDT) Received: from kenawang.windriver.com (dhcp226-6.isi.com [192.216.226.198]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA27873; Thu, 24 Oct 2002 09:16:17 -0700 (PDT) Message-Id: <5.1.0.14.2.20021024121523.02bf86b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 24 Oct 2002 12:17:42 -0400 To: Keith Moore From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <200210241502.g9OF2e014626@astro.cs.utk.edu> References: <(Your message of "Thu, 24 Oct 2002 14:14:40 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.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 think that we should keep site-local addresses in the addressing architecture, but limit their use to non-globally- connected IPv6 networks. Margaret At 11:02 AM 10/24/02, Keith Moore wrote: >we'd be far better off to deprecate site local addresses, as nobody has >actually given a convincing case for their use. >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Oct 24 10:28:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OHSr29018952; Thu, 24 Oct 2002 10:28:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OHSqal018951; Thu, 24 Oct 2002 10:28:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OHSm29018944 for ; Thu, 24 Oct 2002 10:28:48 -0700 (PDT) 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 g9OHSuMq012487 for ; Thu, 24 Oct 2002 10:28:56 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06270 for ; Thu, 24 Oct 2002 11:28:50 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9OHSh015248; Thu, 24 Oct 2002 13:28:43 -0400 (EDT) Message-Id: <200210241728.g9OHSh015248@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 24 Oct 2002 12:17:42 EDT.") <5.1.0.14.2.20021024121523.02bf86b0@mail.windriver.com> Date: Thu, 24 Oct 2002 13:28:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that we should keep site-local addresses in the > addressing architecture, but limit their use to non-globally- > connected IPv6 networks. the problem is that even a network that isn't connected directly to the global internet may have nodes that communicate with other nodes that are connected to the global internet (say through private connections to other networks). so the constraint you propose doesn't relieve apps of the need to be aware of site-locals and network topology. site-locals would be okay for truly isolated networks. the trouble is getting people to understand that isolated really does mean not connected to any other networks. RFC 1918 wouldn't have caused so many problems if people had heeded the limitations imposed on its use. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 10:53:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OHr029019138; Thu, 24 Oct 2002 10:53:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OHr02S019137; Thu, 24 Oct 2002 10:53:00 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OHqv29019130 for ; Thu, 24 Oct 2002 10:52:57 -0700 (PDT) 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 g9OHr5Mq020052 for ; Thu, 24 Oct 2002 10:53:05 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01615 for ; Thu, 24 Oct 2002 10:53:00 -0700 (PDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 24 Oct 2002 10:53:01 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Oct 2002 10:52:59 -0700 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); Thu, 24 Oct 2002 10:52:59 -0700 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: Node Requirements Issue 3 Date: Thu, 24 Oct 2002 10:53:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ7g0yvFhwRt9FoTie6b143SdL5pQAAskkQ From: "Richard Draves" To: "Keith Moore" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 24 Oct 2002 17:52:59.0939 (UTC) FILETIME=[31199730:01C27B86] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9OHqv29019131 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is craziness. We (I don't mean just MS) have shipping implementations that support site-locals. We have operational deployments using site-locals. We have applications that work just fine with site-locals. 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 Thu Oct 24 11:04:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OI4729019251; Thu, 24 Oct 2002 11:04:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OI47xB019250; Thu, 24 Oct 2002 11:04:07 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OI4329019243 for ; Thu, 24 Oct 2002 11:04:03 -0700 (PDT) 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 g9OI4BMq023695 for ; Thu, 24 Oct 2002 11:04:11 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01996 for ; Thu, 24 Oct 2002 11:04:05 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9OI3u015895; Thu, 24 Oct 2002 14:03:57 -0400 (EDT) Message-Id: <200210241803.g9OI3u015895@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 24 Oct 2002 10:53:00 PDT.") Date: Thu, 24 Oct 2002 14:03:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is craziness. We (I don't mean just MS) have shipping > implementations that support site-locals. We have operational > deployments using site-locals. We have applications that work just fine > with site-locals. indeed, some applications work just fine with them. but trying to make applications in general work with limited-scope addresses - that's craziness. fortunately your shipping implementations won't break if site-locals aren't used. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 11:32:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OIWZ29019504; Thu, 24 Oct 2002 11:32:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OIWZHd019503; Thu, 24 Oct 2002 11:32:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OIWW29019496 for ; Thu, 24 Oct 2002 11:32:32 -0700 (PDT) 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 g9OIWebB027671 for ; Thu, 24 Oct 2002 11:32:40 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17130 for ; Thu, 24 Oct 2002 12:32:35 -0600 (MDT) 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 g9OIWQCf038114; Thu, 24 Oct 2002 14:32:26 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OIWQqp186414; Thu, 24 Oct 2002 12:32:26 -0600 In-Reply-To: To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com, "Keith Moore" , "Margaret Wasserman" Subject: RE: Node Requirements Issue 3 MIME-Version: 1.0 Sensitivity: 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 10/24/2002 02:32:18 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 10/24/2002 02:32:18 PM, Serialize complete at 10/24/2002 02:32:18 PM, S/MIME Sign failed at 10/24/2002 02:32:18 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/24/2002 12:32:25, Serialize complete at 10/24/2002 12:32:25 Message-ID: Date: Thu, 24 Oct 2002 14:32:22 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is craziness. We (I don't mean just MS) have shipping > implementations that support site-locals. We have operational > deployments using site-locals. We have applications that work just fine > with site-locals. Could you (or someone else who has this working) publish an ID which describes how site-locals work? I've seen many postings on various aspects of site-locals which do not work as currently defined, from DNS to routing to applications using site-locals in referrals. There have been some proposals on how to address some of these issues, such as updates to dynamic routing protocols, but others (like DNS) don't seem to have any agreed upon solutions in multi-sited configurations and, arguably in the case of DNS, single-sited configurations. Without standards, or at least standards-track IDs, its hard to see how site-locals can be viewed as useful beyond a single-site configuration, with anything beyond that being experimental and/or proprietary. 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 Thu Oct 24 11:34:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OIYY29019533; Thu, 24 Oct 2002 11:34:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OIYYt6019532; Thu, 24 Oct 2002 11:34:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OIYT29019525 for ; Thu, 24 Oct 2002 11:34:29 -0700 (PDT) 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 g9OIYbMq003546 for ; Thu, 24 Oct 2002 11:34:37 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18153 for ; Thu, 24 Oct 2002 12:34:23 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9OIY7016398; Thu, 24 Oct 2002 14:34:07 -0400 (EDT) Message-Id: <200210241834.g9OIY7016398@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Roy Brabson cc: "Richard Draves" , ipng@sunroof.eng.sun.com, "Keith Moore" , "Margaret Wasserman" Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 24 Oct 2002 14:32:22 EDT.") Date: Thu, 24 Oct 2002 14:34:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Without standards, or at least > standards-track IDs, its hard to see how site-locals can be viewed as > useful beyond a single-site configuration, with anything beyond that being > experimental and/or proprietary. more to the point, it's not even clear that we know how to write standards that specify a reasonable way to use site-locals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 12:21:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OJL029019883; Thu, 24 Oct 2002 12:21:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OJL0xk019881; Thu, 24 Oct 2002 12:21:00 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OJKt29019865 for ; Thu, 24 Oct 2002 12:20:56 -0700 (PDT) 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 g9OJL3Mq017127 for ; Thu, 24 Oct 2002 12:21:04 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15382 for ; Thu, 24 Oct 2002 13:20:57 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9OJKaiZ010995; Thu, 24 Oct 2002 15:20:36 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 24 Oct 2002 15:20:36 -0400 Message-ID: <3DB8477E.3040604@nc.rr.com> Date: Thu, 24 Oct 2002 15:18:22 -0400 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: Roy Brabson CC: Richard Draves , ipng@sunroof.eng.sun.com, Keith Moore , Margaret Wasserman Subject: Re: Node Requirements Issue 3 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Roy, Roy Brabson wrote: >>This is craziness. We (I don't mean just MS) have shipping >>implementations that support site-locals. We have operational >>deployments using site-locals. We have applications that work just fine >>with site-locals. > > > Could you (or someone else who has this working) publish an ID which > describes how site-locals work? I've seen many postings on various > aspects of site-locals which do not work as currently defined, from DNS to > routing to applications using site-locals in referrals. There have been > some proposals on how to address some of these issues, such as updates to > dynamic routing protocols, but others (like DNS) don't seem to have any > agreed upon solutions in multi-sited configurations and, arguably in the > case of DNS, single-sited configurations. Without standards, or at least > standards-track IDs, its hard to see how site-locals can be viewed as > useful beyond a single-site configuration, with anything beyond that being > experimental and/or proprietary. I have been meaning to write a draft on what I had to do to routing and forwarding in order to get site-border functionality. But, I don't think that would address the bigger issues that have been discussed. The routing and forwarding is complex, but it doesn't compare to some of the other issues. If anyone wants to hear about what it took to get RIPng to do site border functionality, let me know and I will put something together. 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 Oct 24 13:23:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OKNP29020458; Thu, 24 Oct 2002 13:23:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OKNPSP020457; Thu, 24 Oct 2002 13:23:25 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OKNM29020450 for ; Thu, 24 Oct 2002 13:23:22 -0700 (PDT) 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 g9OKNUMq008566 for ; Thu, 24 Oct 2002 13:23:30 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11817 for ; Thu, 24 Oct 2002 13:23:24 -0700 (PDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9OKN6ib024061; Thu, 24 Oct 2002 16:23:06 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 24 Oct 2002 16:23:32 -0400 Message-ID: <3DB85623.5040007@nc.rr.com> Date: Thu, 24 Oct 2002 16:20:51 -0400 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: Richard Draves CC: Keith Moore , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Just for my edification: 1. Who else has site-local support? 2. Can you describe the operational deployments? 3. What applications? Thanks, Brian Richard Draves wrote: > This is craziness. We (I don't mean just MS) have shipping > implementations that support site-locals. We have operational > deployments using site-locals. We have applications that work just fine > with site-locals. > > 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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 13:57:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OKvE29020930; Thu, 24 Oct 2002 13:57:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OKvE1C020929; Thu, 24 Oct 2002 13:57:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OKvA29020919 for ; Thu, 24 Oct 2002 13:57:10 -0700 (PDT) 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 g9OKvIbB013114 for ; Thu, 24 Oct 2002 13:57:18 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24325 for ; Thu, 24 Oct 2002 14:57:11 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9OKv5KV013414; Thu, 24 Oct 2002 22:57:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Oct 2002 22:57:01 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BDA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , Keith Moore Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Node Requirements Issue 3 Date: Thu, 24 Oct 2002 22:57:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think that we should keep site-local addresses in the > addressing architecture, but limit their use to non-globally- > connected IPv6 networks. > => Agreed. Another useful use is that long lived connections within a site can survive renumbering. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 14:03:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OL3L29021035; Thu, 24 Oct 2002 14:03:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OL3LGg021034; Thu, 24 Oct 2002 14:03:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OL3I29021027 for ; Thu, 24 Oct 2002 14:03:18 -0700 (PDT) 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 g9OL3QbB015325 for ; Thu, 24 Oct 2002 14:03:26 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13029 for ; Thu, 24 Oct 2002 15:03:20 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9OL3JVB044598 for ; Thu, 24 Oct 2002 17:03:19 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OL3IgM093800 for ; Thu, 24 Oct 2002 15:03:18 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9OL0Rr20508 for ; Thu, 24 Oct 2002 17:00:27 -0400 Message-Id: <200210242100.g9OL0Rr20508@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt In-Reply-To: Message from "Michel Py" of "Thu, 24 Oct 2002 08:58:54 PDT." <2B81403386729140A3A899A8B39B046405E3AF@server2000> Date: Thu, 24 Oct 2002 17:00:27 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the size of the prefix to allocate for documentation. In IPv4, the following is reserved per RFC 3330. > 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in > documentation and example code. It is often used in conjunction with > domain names example.com or example.net in vendor and protocol > documentation. Addresses within this block should not appear on the > public Internet. This is far less than is needed (strictly speaking) to document usages that require shorter prefixes. But I'm not aware of this being a problem in practice. I think what we want here is a workable balance between no addresses for documentation at all and allocating too much space in order to document all possibilities. "Michel Py" writes: > Then a /32 is not enough, IMHO. A /32 is the size currently allocated to > LIRs; imagine a sample BGP config that involves three LIRs, you would > need at least three /32s. A /30 would be what I consider the bare > minimum in this case. But can't the same then be said for a 192.0.2.0/24 not being long enough in IPv4? 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 Thu Oct 24 14:39:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OLdZ29021488; Thu, 24 Oct 2002 14:39:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9OLdZu8021487; Thu, 24 Oct 2002 14:39:35 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9OLdV29021480 for ; Thu, 24 Oct 2002 14:39:31 -0700 (PDT) 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 g9OLddMq006007 for ; Thu, 24 Oct 2002 14:39:39 -0700 (PDT) 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 PAA01770 for ; Thu, 24 Oct 2002 15:39:33 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Thu, 24 Oct 2002 14:39:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3B7@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Thread-Index: AcJ7o00Bl3XAyBXPQUmuAJBuDBY9lgAACzwA From: "Michel Py" To: "Thomas Narten" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9OLdW29021481 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > Thomas Narten wrote: > [192.0.2.0/24] > This is far less than is needed (strictly speaking) to > document usages that require shorter prefixes. But I'm > not aware of this being a problem in practice. Because there is a solidly established practice of using RFC1918 addresses for documentation purposes, especially the 10. net. > I think what we want here is a workable balance between > no addresses for documentation at all and allocating too > much space in order to document all possibilities. I agree. A compromise between wasting too much space and a futile attempt to preserve what does not need to. >> Then a /32 is not enough, IMHO. A /32 is the size currently >> allocated to LIRs; imagine a sample BGP config that involves >> three LIRs, you would need at least three /32s. A /30 would >> be what I consider the bare minimum in this case. > But can't the same then be said for a 192.0.2.0/24 not > being long enough in IPv4? Yes, but the situation is not the same: there is no shortage of IPv6 addresses. It's not a reason to waste them, but while assessing this balance we are talking about, ask yourself this question: With the current allocation size for LIRs (/32) there could be 500 million (2^29) LIRs. Is it worthwhile allocating 4 out of these 500 million for documentation purposes? I think so. 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 Oct 24 16:06:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ON6u29022049; Thu, 24 Oct 2002 16:06:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ON6tCl022048; Thu, 24 Oct 2002 16:06:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ON6l29022041 for ; Thu, 24 Oct 2002 16:06:52 -0700 (PDT) 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 g9ON6tbB021089 for ; Thu, 24 Oct 2002 16:06:55 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16685 for ; Thu, 24 Oct 2002 17:06:50 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4I005CADJDNB@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 24 Oct 2002 17:06:50 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4I0063ODJC35@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 24 Oct 2002 17:06:49 -0600 (MDT) Date: Thu, 24 Oct 2002 16:05:49 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt To: Michel Py Cc: ipng@sunroof.eng.sun.com Message-id: <3DB87CCD.6050300@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: <2B81403386729140A3A899A8B39B046405E3B7@server2000> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: >Thomas, > > > >>Thomas Narten wrote: >>[192.0.2.0/24] >>This is far less than is needed (strictly speaking) to >>document usages that require shorter prefixes. But I'm >>not aware of this being a problem in practice. >> >> > >Because there is a solidly established practice of using RFC1918 >addresses for documentation purposes, especially the 10. net. > Bingo! We need to reserve some equivalent space in v6 land. Net 10 allows 16 bits to create a hierachy of /24, so we need 16 bits in v6 lands to create a hierachy of /48. That translate into a /32. - 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 Oct 24 16:28:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ONSS29022160; Thu, 24 Oct 2002 16:28:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ONSSdw022159; Thu, 24 Oct 2002 16:28:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ONSP29022152 for ; Thu, 24 Oct 2002 16:28:25 -0700 (PDT) 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 g9ONSXbB026738 for ; Thu, 24 Oct 2002 16:28:33 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26047 for ; Thu, 24 Oct 2002 17:28:27 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Date: Thu, 24 Oct 2002 16:28:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3B8@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt Thread-Index: AcJ7siaTuTFWVQ1CQCyjOjc27eGlfAAAdifQ From: "Michel Py" To: "Alain Durand" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ONSP29022153 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alain Durand wrote: > We need to reserve some equivalent space in > v6 land. Net 10 allows 16 bits to create a > hierachy of /24, so we need 16 bits in v6 > lands to create a hierachy of /48. That > translate into a /32. Another way to read these numbers: 10. net allows 10 bits to create a hierarchy of /18s (a reasonable size for a v4 ISP, that's 64 class Cs) so we need 10 bits in v6 land to create a hierarchy of /32s, which translates into a /14. You are comparing apples and oranges, this makes no sense. 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 Oct 24 20:45:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P3jp29023032; Thu, 24 Oct 2002 20:45:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P3jpsk023031; Thu, 24 Oct 2002 20:45:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P3jm29023024 for ; Thu, 24 Oct 2002 20:45:48 -0700 (PDT) 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 g9P3jubB013643 for ; Thu, 24 Oct 2002 20:45:56 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05341 for ; Thu, 24 Oct 2002 20:45:50 -0700 (PDT) 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 g9P3jSw20126 for ; Fri, 25 Oct 2002 06:45:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 06:45:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 06:45:47 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node Requirements Issue 3 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 06:45:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A59AD@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ7nDPo2fhyLV/hQlGYpiWqn64FgQAPKaMw To: , Cc: , , X-OriginalArrivalTime: 25 Oct 2002 03:45:47.0485 (UTC) FILETIME=[010268D0:01C27BD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9P3jm29023025 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Rich & Keith, Maybe the best way forward would be to work on a BCP on Site Local addresses. This could point out what site-locals are good for, what they are not good for and some recommendations on using them. John > -----Original Message----- > From: ext Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: 24 October, 2002 23:21 > To: Richard Draves > Cc: Keith Moore; Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Node Requirements Issue 3 > > > Rich, > Just for my edification: > > 1. Who else has site-local support? > > 2. Can you describe the operational deployments? > > 3. What applications? > > Thanks, > Brian > > Richard Draves wrote: > > This is craziness. We (I don't mean just MS) have shipping > > implementations that support site-locals. We have operational > > deployments using site-locals. We have applications that > work just fine > > with site-locals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 20:54:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P3sL29023083; Thu, 24 Oct 2002 20:54:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P3sLe7023082; Thu, 24 Oct 2002 20:54:21 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P3sH29023075 for ; Thu, 24 Oct 2002 20:54:17 -0700 (PDT) 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 g9P3sPMq028280 for ; Thu, 24 Oct 2002 20:54:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18962 for ; Thu, 24 Oct 2002 20:54:20 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9P3sD019250; Thu, 24 Oct 2002 23:54:13 -0400 (EDT) Message-Id: <200210250354.g9P3sD019250@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: bkhabs@nc.rr.com, richdr@microsoft.com, moore@cs.utk.edu, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Fri, 25 Oct 2002 06:45:46 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A59AD@esebe004.ntc.nokia.com> Date: Thu, 24 Oct 2002 23:54:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe the best way forward would be to work on a BCP on Site > Local addresses. This could point out what site-locals are > good for, what they are not good for and some recommendations > on using them. I don't think this would solve the problem that I'm concerned about - which is that the very existence of scoped addresses, coupled with the expectation by sites that it's acceptable to use them by applications, has the effect of damaging reliability and response time of apps that are exposed to such addresses, and drastically increasing the complexity of distributed applications that try to deal with them in a sane fashion. trying to justify SLs in a BCP seems like the wrong approach - it's really not clear that SLs are good for anything or that they should ever be used (except perhaps on completely isolated networks) when you consider the associated costs. IMHO SLs should go the way of A6 records. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 24 22:35:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P5Zv29023638; Thu, 24 Oct 2002 22:35:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P5ZvE3023637; Thu, 24 Oct 2002 22:35:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P5Zr29023630 for ; Thu, 24 Oct 2002 22:35:53 -0700 (PDT) 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 g9P5a1bB029149 for ; Thu, 24 Oct 2002 22:36:01 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04730 for ; Thu, 24 Oct 2002 23:35:55 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO352T34X4905YPF@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 25 Oct 2002 15:33:46 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1491512C01F; Fri, 25 Oct 2002 15:33:44 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 80A0512C015; Fri, 25 Oct 2002 15:33:41 +1000 (EST) Date: Fri, 25 Oct 2002 15:33:41 +1000 From: Greg Daley Subject: Re: Unsolicitated Neighbor Advertisement on Link-Up To: Walter Zimmer Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DB8D7B5.1090606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3DB81B9D.4B457FCD@esk.fhg.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Walter, There's some related discussion going on with the optimistic DAD draft, which proposes this idea as part of the optimization for DAD. Just sending a NA when no-one has data for you may not have any effect though. Greg Daley Walter Zimmer wrote: > Hi! > > When unplugging an IPv6 node from an ethernet switchport and > plugging it back into another, the host is not reachable until > the switching table timeout expired (or any ARP timeout occurs). > > Therefore, in this respect, IPv6 is not superior to IPv4. > > Are there any negative consequences if an IPv6 node sends out > an unsolicitated neighbor advertisement after the link comes up > again? It might choose a random delay (e.g. up to 1 sec), but > I think this would be beneficial in hiding the ugly details of > switching tables from the user. > > Or did I miss it and it is already included in some IPv6 spec? > I looked into NDP (RFC 2461) and IPv6 over Ethernet (RFC 2464). > > Thanks for any info on this topic, > Walter > -- > Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK) > > Walter Zimmer Hansastraße 32 > Dipl.-Inf. D-80686 München > Telefon: +49(0)89-547088-344 > walter.zimmer@esk.fraunhofer.de Telefax: +49(0)89-547088-221 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 25 00:10:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P7AM29024095; Fri, 25 Oct 2002 00:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P7AMro024094; Fri, 25 Oct 2002 00:10:22 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P7AJ29024087 for ; Fri, 25 Oct 2002 00:10:19 -0700 (PDT) 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 g9P7ARMq026461 for ; Fri, 25 Oct 2002 00:10:27 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA20569 for ; Fri, 25 Oct 2002 01:10:10 -0600 (MDT) From: Jonne.Soininen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P7AxU14215 for ; Fri, 25 Oct 2002 02:11:00 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 02:10:09 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 02:10:08 -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: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Date: Fri, 25 Oct 2002 00:10:07 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDB1D@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver" Thread-Index: AcJ48oq8iSMjzBcDQgSLPZ7y0V/sswDAaErw To: Cc: , X-OriginalArrivalTime: 25 Oct 2002 07:10:08.0997 (UTC) FILETIME=[8D70A950:01C27BF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9P7AJ29024088 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > This is the "we need a solution today, it doesn't matter if it is a > crappy solution, we have to have something so we can pretend we have > done all of the work" argument. Some of us are not missing this at > all... Sorry to be a bit unclear. I didn't mean that we should pick a crappy solution. However, if we have a good _enough_ solution (which I believe we have) we shouldn't look for the "Holy Grail" of perfection. To my understanding, they guys writing the draft have done a good job of (at least trying of) doing all the work. Cheers, Jonne. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 25 01:22:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P8MY29024398; Fri, 25 Oct 2002 01:22:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P8MYsL024397; Fri, 25 Oct 2002 01:22:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P8MU29024390 for ; Fri, 25 Oct 2002 01:22:31 -0700 (PDT) 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 g9P8MdMq012324 for ; Fri, 25 Oct 2002 01:22:39 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21436 for ; Fri, 25 Oct 2002 02:22:31 -0600 (MDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de (8.11.6/8.11.6) with ESMTP id g9P8MLd09199; Fri, 25 Oct 2002 10:22:21 +0200 (MEST) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by mailgw1.fraunhofer.de (8.11.6/8.11.6) with ESMTP id g9P8MKD09192; Fri, 25 Oct 2002 10:22:20 +0200 (MEST) Received: from esk.fhg.de (host3-24 [192.168.3.24]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id KAA20086; Fri, 25 Oct 2002 10:22:18 +0200 (MET DST) Message-ID: <3DB8FF3A.3235EB78@esk.fhg.de> Date: Fri, 25 Oct 2002 10:22:18 +0200 From: Walter Zimmer Organization: FhG - ESK X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: ipng@sunroof.eng.sun.com Subject: Re: Unsolicitated Neighbor Advertisement on Link-Up References: <3DB81B9D.4B457FCD@esk.fhg.de> <3DB8D7B5.1090606@eng.monash.edu.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Greg! Greg Daley wrote: > There's some related discussion going on with > the optimistic DAD draft, which proposes this > idea as part of the optimization for DAD. Thanks for the pointer to this interesting (yet lengthy :) discussion. I still see differences between the operation proposed in the O-DAD draft and the mechanism used here: In the draft, a router advertisement with a different prefix is the trigger for the UNA, whereas here it is the link state transition to 'up'. If an IPv6 router sends a NA on link up (it doesn't ?), there still is no change of routing prefix involved here. Therefore, I think this application should be restricted to the ethernet link layer. > Just sending a NA when no-one has data for you > may not have any effect though. The host might remember if there was traffic going on before the link went to 'down' state. Yet, I would assume that the benefit of saving NAs doesn't outweight the cost involved. Walter -- Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK) Walter Zimmer Hansastraße 32 Dipl.-Inf. D-80686 München Telefon: +49(0)89-547088-344 walter.zimmer@esk.fraunhofer.de Telefax: +49(0)89-547088-221 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 25 02:23:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9No29024672; Fri, 25 Oct 2002 02:23:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P9NoCY024671; Fri, 25 Oct 2002 02:23:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9Nk29024664 for ; Fri, 25 Oct 2002 02:23:46 -0700 (PDT) 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 g9P9NtbB002728 for ; Fri, 25 Oct 2002 02:23:55 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00567 for ; Fri, 25 Oct 2002 03:23:37 -0600 (MDT) 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 g9P9MuT29361; Fri, 25 Oct 2002 16:22:56 +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 g9NB5o201593; Wed, 23 Oct 2002 18:05:50 +0700 (ICT) From: Robert Elz To: Keith Moore cc: "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-Reply-To: <200210221741.g9MHfv019352@astro.cs.utk.edu> References: <200210221741.g9MHfv019352@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Oct 2002 18:05:50 +0700 Message-ID: <1591.1035371150@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 22 Oct 2002 13:41:57 -0400 From: Keith Moore Message-ID: <200210221741.g9MHfv019352@astro.cs.utk.edu> | if an app has multiple addresses to choose from, and some work better | than others, and the ability of the app to function effectively | involves choosing an address, the app essentially needs routing | information in order to make that choice. Not really, it needs something similar perhaps, but it isn't routing information. And in any case, this is true any time there are multiple possible addresses, scoping of some addresses has nothing to do with it. | yes, this possibility always exists. but we used to have a clean | separation of function between the apps and the network We still do, nothing has really changed. | these days we are starting to expect the app (or more naively | the host) to make decisions that require routing information, but without | giving them the routing information. Once again, it is not routing. Routing information isn't required. | that was a fine strategy when a host had only a couple of addresses, and | they were global, and all of the addresses worked most of the time. | it doesn't work well when hosts have several addresses of varying | scope, especially when combined with very ephemeral address-to-host | bindings. Much of that is just the same for v6, except that hosts might have lots more addresses, and v4 or v6, name to address bindings don't last forever any more. | and once you start trying to figure how to describe scopes you | find that what you really need is a global address space and routing | information. Global address space yes, routing information no. And the former assumes that we actually want to deal with limited scope addresses at a global level, which we almost certainly don't. Dealing with them at a local level is sufficient. | otherwise, what you're essentially saying is that having limited-scope | addresses causes no problems that aren't addressed as soon as we have | a solution to this other unsolved problem... no, we don't need to solve the hard problem to make them useful. | > I know you're concerned about apps (protocols) which pass around addresses | > in the data (and consequently which aren't limited by the normal scope | > control measures). Where that happens the apps just need to take care not | > to pass an address to a node where it isn't known to be meaningful. | | there's no way for the app to know that. Which is ... | > Since that's hard to determine, a simpler rule that works, is simply never | > to pass an address of a lesser scope (more restricted scope) than the | > address being used for the peer in the communications over which the | > address is to be sent. what I just said. | no, this isn't sufficient either because the app has no idea of the peer's | scope, much less the scope of the eventual users of those addresses. No, you didn't read what I wrote, I suspect. If A and B are communicating using global addresses, then A sends B only global addresses. If A and B are communicating using SL addresses (zone x) then A sends B only global addresses, and SL addresses in zone x, which must be meaningful. If B wants to send on the addresses to somewhere else (C) then it follows exactly the same rule (and drops any SL zone x addresses if the would have to go somewhere that isn't known to be in SL zone x). If it turns out that there is no address left to send, then A & C can't communicate, but that's evidently what was desired when the addresses were assigned in the first place. If the administrators actually desire to prevent hosts communicating, then that's what should be done. In most cases, there will be global addresses, they'll work, and the issue of whether some SL or even LL address might also work won't be terribly relevant. The info that an app needs to make these particular choices is trivially easily available, and while it is extra work that apps haven't done before, it is by no means difficult to manage. What is needed is that we get beyond the "here is THE address you must use" methedology, and always allow a set of addresses to be communicated (either directly, or by sending a name and having the recipient do name to address translation). 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 Oct 25 02:23:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9Nd29024662; Fri, 25 Oct 2002 02:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P9NdMj024661; Fri, 25 Oct 2002 02:23:39 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9NZ29024654 for ; Fri, 25 Oct 2002 02:23:35 -0700 (PDT) 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 g9P9NhMq020496 for ; Fri, 25 Oct 2002 02:23:44 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13530 for ; Fri, 25 Oct 2002 03:23:32 -0600 (MDT) 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 g9P9MgT29293; Fri, 25 Oct 2002 16:22:42 +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 g9NBMa201633; Wed, 23 Oct 2002 18:22:36 +0700 (ICT) From: Robert Elz To: "sasson, shuki" cc: Keith Moore , Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-Reply-To: <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> References: <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Oct 2002 18:22:36 +0700 Message-ID: <1631.1035372156@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 22 Oct 2002 08:47:54 -0400 From: "sasson, shuki" Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> | Link Local addresses should be globally unique addresses so scoping | shouldn't be a problem (64 bits should do...). It is all evry nice to desire this, but useless unless we have some mechanism for actually making it happen. And we don't. Take SL addresses for a minute (where the issues this way are a little easier - LL's need to be available to a node before it actually starts communicating on the net, which makes them very hard to deal with). SL's have a whole bunch of bits that was decided at Yokohama, and not clallenged on the list, will be available to be considered as part of the SL address - easily enough for everyone to have a a unique SL address prefix (not routable, but unique). But actually making that happen would require a whole identifier assignment bureaucracy, and no-one wants to actually create (yet another) entity like that. So, instead, sites just invent their own identifiers (perhaps in co-ordination with other sites that they might some day want to exchange SL info with) and they're not expected to be unique. 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 Oct 25 02:24:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9Ot29024695; Fri, 25 Oct 2002 02:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9P9Ot5U024694; Fri, 25 Oct 2002 02:24:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9P9Om29024680 for ; Fri, 25 Oct 2002 02:24:49 -0700 (PDT) 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 g9P9OvbB002880 for ; Fri, 25 Oct 2002 02:24:57 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23468 for ; Fri, 25 Oct 2002 02:24:46 -0700 (PDT) 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 g9P9MtT29358; Fri, 25 Oct 2002 16:22:55 +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 g9NAh7201527; Wed, 23 Oct 2002 17:43:07 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: ipng@sunroof.eng.sun.com, ono@kame.net Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <20021023033632.42ADF7BA@starfruit.itojun.org> References: <20021023033632.42ADF7BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Oct 2002 17:43:07 +0700 Message-ID: <1525.1035369787@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 23 Oct 2002 12:36:32 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20021023033632.42ADF7BA@starfruit.itojun.org> | another example of complication due to the scoped address. | (previous example was FTP) FTP in general is an interesting case to look at (though as people use it in practice, with 3-way FTP prohibited, it turns out to be no different than anything else), but ... | X uses xhost(1) to control accesses to X server. For instance, | % xhost +10.1.1.1 isn't really interesting at all. xhost is an administrative tool for controlling the server. Any addresses involved are clearly in the context of the X server - they're used only to compare the source of incoming connections. Whether or not the address means anything, be it the same thing or a different one, at the client (where the xhost command is run), or nothing at all, is really irrelevant. There's certainly an issue of translating names to addresses in the context of the server, at some other location, but that's really the only issue. Where the X server lives only in one zone (or each scope) there's no scoping issues at all really. Where it lives in more than one, then technically, one would want to allow the server to accept connections from fe80:;1 in zone 1, but not fe80::1 in zone 2. There's no way for xhost to accomplish that (I expect, without looking at how X has been extended to permit v6 addresses - if done properly, there would be room there for a scope identifier) but this could just be added on as yet another limitation of the xhost "authentication" mechanism - allowing connections from one address, would also allow connections from other clients that have the same address, in other zones that can reach the X server. Big deal .... xhost is trash that no-one who actually cares about real access control of their X servers uses anyway. | one possible solution would be to make xhost(1) transmit addresses | as a string, and let X server decode it. even so, the user of xhost(1) | has to know the view of the scope on the machine running X server. Yes. Anyone running xhost should understand the context of the X server. That's beyond doubt, address scopes are just one more issue that needs to be understood (and one more reason to discard xhost completely). 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 Oct 25 05:12:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PCCS29025185; Fri, 25 Oct 2002 05:12:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PCCSdq025184; Fri, 25 Oct 2002 05:12:28 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PCCN29025177 for ; Fri, 25 Oct 2002 05:12:23 -0700 (PDT) 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 g9PCCVMq011447 for ; Fri, 25 Oct 2002 05:12:31 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23832 for ; Fri, 25 Oct 2002 06:12:25 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PC8R020028; Fri, 25 Oct 2002 08:08:28 -0400 (EDT) Message-Id: <200210251208.g9PC8R020028@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , "Brian Zill" , "sasson, shuki" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Wed, 23 Oct 2002 18:05:50 +0700.") <1591.1035371150@munnari.OZ.AU> Date: Fri, 25 Oct 2002 08:08:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Tue, 22 Oct 2002 13:41:57 -0400 > From: Keith Moore > Message-ID: <200210221741.g9MHfv019352@astro.cs.utk.edu> > > | if an app has multiple addresses to choose from, and some work better > | than others, and the ability of the app to function effectively > | involves choosing an address, the app essentially needs routing > | information in order to make that choice. > > Not really, it needs something similar perhaps, but it isn't routing > information. let's put it this way - it needs information that is currently only available to the routing system, and isn't easily provided to hosts in any case. > And in any case, this is true any time there are multiple > possible addresses, scoping of some addresses has nothing to do with it. before IPv6 it has generally been sufficient if all addresses worked well, most of the time. one reason we didn't use multiple addresses as a means of providing redundant access in IPv4 is that it didn't work well - despite that, we somehow expect it to work well in IPv6. > | yes, this possibility always exists. but we used to have a clean > | separation of function between the apps and the network > > We still do, nothing has really changed. false. now we are expecting apps to make sense of a hodgepodge of addresses, some of which work only ephemerally, others of which are ambiguous, others of which work only in certain portions of the network. we're even saying that it's okay to expect apps to deal with hosts that only have addresses that are impaired in one or more of these ways - and apps have no way of knowing which addreses will work from a particular host at a particular time. > | that was a fine strategy when a host had only a couple of addresses, and > | they were global, and all of the addresses worked most of the time. > | it doesn't work well when hosts have several addresses of varying > | scope, especially when combined with very ephemeral address-to-host > | bindings. > > Much of that is just the same for v6, except that hosts might have > lots more addresses, and v4 or v6, name to address bindings don't last > forever any more. you might think of this as just a difference in degree, but it's a huge difference. > | and once you start trying to figure how to describe scopes you > | find that what you really need is a global address space and routing > | information. > > Global address space yes, routing information no. And the former > assumes that we actually want to deal with limited scope addresses > at a global level, which we almost certainly don't. Dealing with > them at a local level is sufficient. apps don't recognize topology boundaries - actually apps are routinely expected to work across topology boundaries. > | otherwise, what you're essentially saying is that having limited-scope > | addresses causes no problems that aren't addressed as soon as we have > | a solution to this other unsolved problem... > > no, we don't need to solve the hard problem to make them useful. yes, they can be useful - the question is whether they are worth the cost. the answer is no. > No, you didn't read what I wrote, I suspect. If A and B are communicating > using global addresses, then A sends B only global addresses. If A and > B are communicating using SL addresses (zone x) then A sends B only global > addresses, and SL addresses in zone x, which must be meaningful. If B > wants to send on the addresses to somewhere else (C) then it follows exactly > the same rule (and drops any SL zone x addresses if the would have to go > somewhere that isn't known to be in SL zone x). you're being overly simplistic. A and B don't have any idea whether their addresses are going to be used, whether or not they'll be used in a zone where they mean the same thing to nodes there that they mean to A and B. that and you're expecting applications to absorb a great deal of additional complexity for a very marginal gain. > If it turns out that there is no address left to send, then A & C can't > communicate, but that's evidently what was desired when the addresses were > assigned in the first place. If the administrators actually desire to > prevent hosts communicating, then that's what should be done. it's bad architecture to try to use address bits to indicate whether hosts are restricted from communicating. if hosts aren't supposed to communicate, the right solution is to block their communication at firewalls, not to expect every host/app to maintain a large 'key ring' of addresses. > In most cases, there will be global addresses, they'll work, and the issue > of whether some SL or even LL address might also work won't be terribly > relevant. seems like a dubious assumption given the way that SL and LL are being promoted. > The info that an app needs to make these particular choices is trivially > easily available, and while it is extra work that apps haven't done before, > it is by no means difficult to manage. as a writer of distributed apps, I emphatically disagree. > What is needed is that we get beyond the "here is THE address you must > use" methedology, and always allow a set of addresses to be communicated > (either directly, or by sending a name and having the recipient do name > to address translation). what is needed is to actually understand the implications of what you propose. I've tried to write code to do this, and it's really difficult. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 05:39:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PCdM29025261; Fri, 25 Oct 2002 05:39:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PCdMwY025260; Fri, 25 Oct 2002 05:39:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PCdJ29025253 for ; Fri, 25 Oct 2002 05:39:19 -0700 (PDT) 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 g9PCdRbB028051 for ; Fri, 25 Oct 2002 05:39:27 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18426 for ; Fri, 25 Oct 2002 05:39:21 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA12551; Fri, 25 Oct 2002 13:39:21 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt From: Ole Troan Date: Fri, 25 Oct 2002 13:39:21 +0100 Message-ID: <7t5hefaitfq.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk new revision of the DHCP PD draft is out. comment appreciated. /ot A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Pages : 18 Date : 2002-10-24 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This prefix delegation mechanism is intended for simple prefix delegation from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 07:27:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PERW29025546; Fri, 25 Oct 2002 07:27:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PERWv9025545; Fri, 25 Oct 2002 07:27:32 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PERT29025538 for ; Fri, 25 Oct 2002 07:27:29 -0700 (PDT) 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 g9PERbMq004767 for ; Fri, 25 Oct 2002 07:27:37 -0700 (PDT) Received: from srexchimc2.lss.emc.com ([168.159.40.71]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24620 for ; Fri, 25 Oct 2002 08:27:32 -0600 (MDT) Received: by srexchimc2.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 10:26:55 -0400 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE4B@srmoon> From: "sasson, shuki" To: "'Robert Elz'" , "sasson, shuki" Cc: Keith Moore , Brian Zill , ipng@sunroof.eng.sun.com Subject: RE: Link Local Address usage for multi-home host. --- Still a pr oblem even using Zones. Date: Fri, 25 Oct 2002 10:23:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am following closely what is written here. Also I am thinking about various solutions to the problem assuming LL uniqueness is not guaranteed (someone told me it is guaranteed for Etherenet is that correct?). Lets say that as an implementers of a File Server we are implementing the extra step of zones. This means basically that we add a zone to each LL source address to identify from which interface it was approaching... Consider the following scenario: Our multihome server is connected through a switch to multiple clients, all on the same broadcast domain (link-local). Lets say now that all the clients are using Link Local addresses. Both Interfaces will view the same Link Local set of addresses but with different zones (different interface...). The routing table/applications will consider them as different entities! I have no doubts that this will create all sorts of bugs in applications that will treat those as two separate entities. What this means is that now the multihome host will have to apply some zone discovery methods (I don't know how, god help us...). First Question -------------- Any Ideas How The above can be resolved? We are supplying our customers with ability to restrict access from some clients and grant an access to others. Lets say that in a Link Local environment the customer assigns global addresses for all the clients and the server. Since the it is a link Local environment the client contacts the server using the LL address (Is that true?) and all these restrictions are bypassed... Second Question ---------------- Will a client will use the global assigned address to communicate in this case or the LL? Third Question --------------- Lets say, we can't make any assumption about the address (meaning the client may choose either global or LL). Let say we have 3 interfaces of the server connected through a switch to all the clients. Will that mean that the poor network manager will have to assign this restrictions 3 times for each LL + zone on each interface? Comment -------- What a mess... Am I missing something? Shuki -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Wednesday, October 23, 2002 7:23 AM To: sasson, shuki Cc: Keith Moore; Brian Zill; ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. Date: Tue, 22 Oct 2002 08:47:54 -0400 From: "sasson, shuki" Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon> | Link Local addresses should be globally unique addresses so scoping | shouldn't be a problem (64 bits should do...). It is all evry nice to desire this, but useless unless we have some mechanism for actually making it happen. And we don't. Take SL addresses for a minute (where the issues this way are a little easier - LL's need to be available to a node before it actually starts communicating on the net, which makes them very hard to deal with). SL's have a whole bunch of bits that was decided at Yokohama, and not clallenged on the list, will be available to be considered as part of the SL address - easily enough for everyone to have a a unique SL address prefix (not routable, but unique). But actually making that happen would require a whole identifier assignment bureaucracy, and no-one wants to actually create (yet another) entity like that. So, instead, sites just invent their own identifiers (perhaps in co-ordination with other sites that they might some day want to exchange SL info with) and they're not expected to be unique. 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 Oct 25 08:22:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PFMR29025667; Fri, 25 Oct 2002 08:22:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PFMRfs025666; Fri, 25 Oct 2002 08:22:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PFMM29025659 for ; Fri, 25 Oct 2002 08:22:22 -0700 (PDT) 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 g9PFMUbB025064 for ; Fri, 25 Oct 2002 08:22:30 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24409 for ; Fri, 25 Oct 2002 09:22:24 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PFH9021452; Fri, 25 Oct 2002 11:17:09 -0400 (EDT) Message-Id: <200210251517.g9PFH9021452@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com, ono@kame.net Subject: Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt In-reply-to: (Your message of "Wed, 23 Oct 2002 17:43:07 +0700.") <1525.1035369787@munnari.OZ.AU> Date: Fri, 25 Oct 2002 11:17:09 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | X uses xhost(1) to control accesses to X server. For instance, > | % xhost +10.1.1.1 > > isn't really interesting at all. xhost is an administrative tool for > controlling the server. Any addresses involved are clearly in the > context of the X server - they're used only to compare the source of > incoming connections. xhost is based on the reasonable assumption that address space was shared by the client and the server. are you really claiming that you expect mere *users* (not just hosts and apps) need to be to keep track of address scopes? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 25 10:45:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PHjk29026896; Fri, 25 Oct 2002 10:45:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PHjjk3026895; Fri, 25 Oct 2002 10:45:45 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PHjg29026888 for ; Fri, 25 Oct 2002 10:45:42 -0700 (PDT) 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 g9PHjoMq026333 for ; Fri, 25 Oct 2002 10:45:51 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09086 for ; Fri, 25 Oct 2002 11:45:45 -0600 (MDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 25 Oct 2002 10:45:44 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Oct 2002 10:45:44 -0700 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, 25 Oct 2002 10:45:46 -0700 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: Node Requirements Issue 3 Date: Fri, 25 Oct 2002 10:46:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ7i72ooc5jn3sFSYe7hbyN6bXehwAwEn1A From: "Richard Draves" To: "Roy Brabson" Cc: X-OriginalArrivalTime: 25 Oct 2002 17:45:46.0034 (UTC) FILETIME=[58E2B120:01C27C4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9PHjg29026889 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How do site-locals work? For a single-sited host, I think the main requirement is draft-ietf-ipv6-default-addr-select-09. For applications that send addresses to correspondents (note this is a small minority of applications) it can get more complicated but it's still not bad - see kre's recent emails about this. I know MS is porting/developing such applications but I'm not involved. For DNS, I implemented draft-ietf-ipngwg-site-prefixes-05 and it works great. Unfortunately since that draft seems to be dead, I think the fall-back for now is that to use site-locals you'll need a two-faced DNS. For a multi-sited host, one additional requirement is that applications should deal with sockaddrs instead of directly with addresses, so that the scope-id is preserved & passed around as needed. Another additional requirement is routing table lookup needs to be cognizant of scoping. We recently implemented some logic to infer when two interfaces are in different sites in many common scenarios (eg when you VPN into an intranet, the VPN interface gets a different site scope-id) but in general manual configuration may be required to specify which interfaces belong to which sites. Rich > -----Original Message----- > From: Roy Brabson [mailto:rbrabson@us.ibm.com] > Sent: Thursday, October 24, 2002 11:32 AM > To: Richard Draves > Cc: ipng@sunroof.eng.sun.com; Keith Moore; Margaret Wasserman > Subject: RE: Node Requirements Issue 3 > > > > This is craziness. We (I don't mean just MS) have shipping > > implementations that support site-locals. We have operational > > deployments using site-locals. We have applications that work just > > fine with site-locals. > > Could you (or someone else who has this working) publish an ID which > describes how site-locals work? I've seen many postings on various > aspects of site-locals which do not work as currently > defined, from DNS to > routing to applications using site-locals in referrals. > There have been > some proposals on how to address some of these issues, such > as updates to > dynamic routing protocols, but others (like DNS) don't seem > to have any > agreed upon solutions in multi-sited configurations and, > arguably in the > case of DNS, single-sited configurations. Without standards, > or at least > standards-track IDs, its hard to see how site-locals can be viewed as > useful beyond a single-site configuration, with anything > beyond that being > experimental and/or proprietary. > > 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 Oct 25 10:47:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PHlq29026916; Fri, 25 Oct 2002 10:47:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PHlqL0026915; Fri, 25 Oct 2002 10:47:52 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PHlm29026908 for ; Fri, 25 Oct 2002 10:47:49 -0700 (PDT) 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 g9PHlvMq027056 for ; Fri, 25 Oct 2002 10:47:57 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10491 for ; Fri, 25 Oct 2002 11:47:52 -0600 (MDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 25 Oct 2002 10:47:55 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Oct 2002 10:47:48 -0700 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 25 Oct 2002 10:47:51 -0700 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: Link Local Address usage for multi-home host. Date: Fri, 25 Oct 2002 10:48:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link Local Address usage for multi-home host. Thread-Index: AcJ8IGRXf/nrAWuvRXyIX71WmmuvmgALhu1A From: "Richard Draves" To: "Keith Moore" , "Robert Elz" Cc: X-OriginalArrivalTime: 25 Oct 2002 17:47:51.0340 (UTC) FILETIME=[A392DEC0:01C27C4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9PHln29026909 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > that and you're expecting applications to absorb a great deal > of additional complexity for a very marginal gain. I would characterize this trade-off differently - it's a small amount of additional complexity for a small fraction of applications, for a reasonable gain. 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 Oct 25 11:18:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PIID29027119; Fri, 25 Oct 2002 11:18:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PIIDQR027118; Fri, 25 Oct 2002 11:18:13 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PII929027111 for ; Fri, 25 Oct 2002 11:18:09 -0700 (PDT) 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 g9PIIIMq008003 for ; Fri, 25 Oct 2002 11:18:18 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06827 for ; Fri, 25 Oct 2002 12:18:12 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 30C6A2E3C; Fri, 25 Oct 2002 14:18:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Oct 2002 14:18:11 -0400 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: Node Requirements Issue 3 Date: Fri, 25 Oct 2002 14:18:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE96C1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ7ky0gc+qXDx/nTuK/p2KSbqaZbgAv55tg From: "Bound, Jim" To: "Brian Haberman" , "Roy Brabson" Cc: "Richard Draves" , , "Keith Moore" , "Margaret Wasserman" X-OriginalArrivalTime: 25 Oct 2002 18:18:11.0908 (UTC) FILETIME=[E0B78040:01C27C52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9PIIA29027112 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, This would be like real valuable to hear real ops/implementation experience. /jim > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: Thursday, October 24, 2002 3:18 PM > To: Roy Brabson > Cc: Richard Draves; ipng@sunroof.eng.sun.com; Keith Moore; > Margaret Wasserman > Subject: Re: Node Requirements Issue 3 > > > Hi Roy, > > Roy Brabson wrote: > >>This is craziness. We (I don't mean just MS) have shipping > >>implementations that support site-locals. We have operational > >>deployments using site-locals. We have applications that work just > >>fine with site-locals. > > > > > > Could you (or someone else who has this working) publish an ID which > > describes how site-locals work? I've seen many postings on various > > aspects of site-locals which do not work as currently > defined, from DNS to > > routing to applications using site-locals in referrals. > There have been > > some proposals on how to address some of these issues, such > as updates to > > dynamic routing protocols, but others (like DNS) don't seem > to have any > > agreed upon solutions in multi-sited configurations and, > arguably in the > > case of DNS, single-sited configurations. Without > standards, or at least > > standards-track IDs, its hard to see how site-locals can be > viewed as > > useful beyond a single-site configuration, with anything > beyond that being > > experimental and/or proprietary. > > I have been meaning to write a draft on what I had to do to > routing and forwarding in order to get site-border > functionality. But, I don't think that would address the > bigger issues that have been discussed. The routing and > forwarding is complex, but it doesn't compare to some of the > other issues. > > If anyone wants to hear about what it took to get RIPng to do > site border functionality, let me know and I will put > something together. > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 11:25:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PIPa29027164; Fri, 25 Oct 2002 11:25:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PIPZXr027163; Fri, 25 Oct 2002 11:25:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PIPV29027156 for ; Fri, 25 Oct 2002 11:25:31 -0700 (PDT) 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 g9PIPdbB017501 for ; Fri, 25 Oct 2002 11:25:40 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08892 for ; Fri, 25 Oct 2002 12:25:34 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PILf021995; Fri, 25 Oct 2002 14:21:41 -0400 (EDT) Message-Id: <200210251821.g9PILf021995@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: Link Local Address usage for multi-home host. In-reply-to: (Your message of "Fri, 25 Oct 2002 10:48:09 PDT.") Date: Fri, 25 Oct 2002 14:21:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would characterize this trade-off differently - it's a small amount of > additional complexity for a small fraction of applications, for a > reasonable gain. the gains seem dubious at best. and you can't judge the harm by considering only the # of applications affected - you also need to consider how useful/important those applications would be. as for the amount of additional complexity, you're completely wrong about that. effectively constraining the network to be client-server doesn't seem like a step forward. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 11:28:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PIS629027195; Fri, 25 Oct 2002 11:28:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PIS6iL027194; Fri, 25 Oct 2002 11:28:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PIS329027187 for ; Fri, 25 Oct 2002 11:28:03 -0700 (PDT) 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 g9PISBbB018297 for ; Fri, 25 Oct 2002 11:28:11 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11666 for ; Fri, 25 Oct 2002 12:28:01 -0600 (MDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9PIRsaZ200566; Fri, 25 Oct 2002 14:27:55 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9PIRqtO064928; Fri, 25 Oct 2002 14:27:52 -0400 In-Reply-To: To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com Subject: RE: Node Requirements Issue 3 MIME-Version: 1.0 Sensitivity: 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 10/25/2002 02:27:45 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 10/25/2002 02:27:45 PM, Serialize complete at 10/25/2002 02:27:45 PM, S/MIME Sign failed at 10/25/2002 02:27:45 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/25/2002 12:27:53, Serialize complete at 10/25/2002 12:27:53 Message-ID: Date: Fri, 25 Oct 2002 14:27:51 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How do site-locals work? > > For a single-sited host, I think the main requirement is > draft-ietf-ipv6-default-addr-select-09. For applications that send > addresses to correspondents (note this is a small minority of > applications) it can get more complicated but it's still not bad - see > kre's recent emails about this. I know MS is porting/developing such > applications but I'm not involved. I'd agree as long as the single-sited host is not connected to the global internet. When connected to the global internet, many applications will work just fine. But there are some application protocols as currently defined which do not work. It would seem useful to try to identify the classes of applications which break in these configurations and what actions need to take to occur to update the protocols and/or applications to allow this to work. Once this is understood, it would be easier to gauge whether using site-local addresses when a site is connected to the global internet is worth the effort. > For DNS, I implemented draft-ietf-ipngwg-site-prefixes-05 and it works > great. Unfortunately since that draft seems to be dead, I think the > fall-back for now is that to use site-locals you'll need a two-faced > DNS. Yes, although not pretty two-faced DNS works for single-sited hosts. > For a multi-sited host, one additional requirement is that applications > should deal with sockaddrs instead of directly with addresses, so that > the scope-id is preserved & passed around as needed. Another additional > requirement is routing table lookup needs to be cognizant of scoping. If the DNS resolver fills in the appropriate scope zone ID for site-local addresses, then the application can use the sockaddr for communication. How the scope zone ID gets filled in, and how the DNS resolver queries two-faced DNS name servers in different sites and consolidates the (now different) responses is what has not been defined. For instance, since each site would need to run two-faced DNS to allow site-locals to be placed in DNS, each may return different results for the same host. Depending on which site the DNS query is sent and how DNS is configured, the resolver may receive no addresses, only global addresses, or a mixture of global and site-local addresses. This was covered on this list previously with no agreed-upon resolution on how to make this work, not to mention any IDs with concrete proposals to be reviewed. There are, of course, additional issues for multi-sited hosts. At a minimum, there are the routing changes which have been discussed here previously, and possibly others which have yet to be identified. None of this is insurmountable. With sufficient architecture and updates to susceptible applications, support for multi-sited hosts can likely be made functional. Whether it is worth the effort is a different question, though, and one which only this WG can answer. 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 Oct 25 12:08:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJ8Y29027492; Fri, 25 Oct 2002 12:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PJ8YYa027491; Fri, 25 Oct 2002 12:08:34 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJ8V29027484 for ; Fri, 25 Oct 2002 12:08:31 -0700 (PDT) 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 g9PJ8dMq023771 for ; Fri, 25 Oct 2002 12:08:40 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06684 for ; Fri, 25 Oct 2002 13:08:33 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9PJ8Os93109; Fri, 25 Oct 2002 15:08:24 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9PJ8Nj83370; Fri, 25 Oct 2002 15:08:23 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id PAA29536; Fri, 25 Oct 2002 15:08:17 -0400 (EDT) Subject: Re: Node Requirements Issue 3 From: Steven Blake To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200210241502.g9OF2e014626@astro.cs.utk.edu> References: <200210241502.g9OF2e014626@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 25 Oct 2002 16:08:16 -0300 Message-Id: <1035572897.24814.110.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-10-24 at 12:02, Keith Moore wrote: > we'd be far better off to deprecate site local addresses, as nobody has > actually given a convincing case for their use. Site locals as defined in draft-ietf-ipngwg-addr-arch-v3-10.txt are functionally no different than RFC 1918 addresses for IPv4. Long term, less chaos will result if a block of addresses is set aside as "unregulated spectrum" than if folks start configuring prefixes out of the ~73% of the address space that is currently unassigned. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 25 12:08:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJ8u29027502; Fri, 25 Oct 2002 12:08:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PJ8tHN027501; Fri, 25 Oct 2002 12:08:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJ8o29027494 for ; Fri, 25 Oct 2002 12:08:50 -0700 (PDT) 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 g9PJ8wbB000121 for ; Fri, 25 Oct 2002 12:08:58 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20709 for ; Fri, 25 Oct 2002 13:08:53 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PJ8o022358; Fri, 25 Oct 2002 15:08:50 -0400 (EDT) Message-Id: <200210251908.g9PJ8o022358@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Roy Brabson" , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Fri, 25 Oct 2002 10:46:01 PDT.") Date: Fri, 25 Oct 2002 15:08:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How do site-locals work? > > For a single-sited host, I think the main requirement is > draft-ietf-ipv6-default-addr-select-09. For applications that send > addresses to correspondents (note this is a small minority of > applications) the number of applications is irrelevant. what's important is how badly this impairs the functionality of the Internet. performance- sensitive apps need to pass addresses around. > it can get more complicated but it's still not bad - see > kre's recent emails about this. if each hosts prunes the addresses it advertises, it prevents some things from working. example: A and B use C as an intermediary; A and B each advertise their addresses to C. A and B share an address scope which isn't accessible by C. So if A prunes its addresses when giving them to C, C isn't able to give B an address that it can use. Of course that is assuming that A knows which address scopes C has access to, which it doesn't. > For DNS, I implemented draft-ietf-ipngwg-site-prefixes-05 and it works > great. Unfortunately since that draft seems to be dead, I think the > fall-back for now is that to use site-locals you'll need a two-faced > DNS. DNS has the same problem as any other app that does referrals - it has no way of knowing which address scopes are accessible to the user of those addresses. > For a multi-sited host, one additional requirement is that applications > should deal with sockaddrs instead of directly with addresses, so that > the scope-id is preserved & passed around as needed. no, you can't pass sockaddrs across the net. > Another additional > requirement is routing table lookup needs to be cognizant of scoping. no, that's just too much hair. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 12:10:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJAM29027526; Fri, 25 Oct 2002 12:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PJAMHD027525; Fri, 25 Oct 2002 12:10:22 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJAH29027518 for ; Fri, 25 Oct 2002 12:10:17 -0700 (PDT) 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 g9PJAPMq024216 for ; Fri, 25 Oct 2002 12:10:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07740 for ; Fri, 25 Oct 2002 13:10:20 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PJAH022392; Fri, 25 Oct 2002 15:10:17 -0400 (EDT) Message-Id: <200210251910.g9PJAH022392@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Roy Brabson cc: "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Fri, 25 Oct 2002 14:27:51 EDT.") Date: Fri, 25 Oct 2002 15:10:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > None of this is insurmountable. With sufficient architecture and updates > to susceptible applications, support for multi-sited hosts can likely be > made functional. Whether it is worth the effort is a different question, > though, and one which only this WG can answer. actually I doubt this wg has enough expertise in applications to be able to answer that question. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 12:39:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJdl29027890; Fri, 25 Oct 2002 12:39:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PJdlPc027889; Fri, 25 Oct 2002 12:39:47 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PJdi29027882 for ; Fri, 25 Oct 2002 12:39:44 -0700 (PDT) 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 g9PJdqMq006778 for ; Fri, 25 Oct 2002 12:39:52 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24707 for ; Fri, 25 Oct 2002 13:39:47 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.46.218]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA07836 for ; Fri, 25 Oct 2002 12:39:43 -0700 (PDT) Message-Id: <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Oct 2002 15:40:30 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 In-Reply-To: <5.1.0.14.2.20021024121523.02bf86b0@mail.windriver.com> References: <200210241502.g9OF2e014626@astro.cs.utk.edu> <(Your message of "Thu, 24 Oct 2002 14:14:40 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:17 PM 10/24/02, Margaret Wasserman wrote: >I think that we should keep site-local addresses in the >addressing architecture, but limit their use to non-globally- >connected IPv6 networks. Some folks have pointed out that it might have been helpful if I had explained my reasoning... The addressing architecture currently defines a set of addresses that are allocated for use as "site-local unicast addresses", but it does not discuss the details of when or how those addresses can or should be used. The scoped addressing architecture document defines how site-local unicast addresses (and other scoped addresses) will be used, and defines node behaviour related to these addresses. I am suggesting that we should consider placing some restrictions on the _use_ of site-local addresses in the scoped addressing architecture document. However, it is imperative that the site-local address allocation remain in the addressing architecture, even if we do decide that the use of these addresses should be restricted (or even forbidden). The allocation has been there for several years, and there are some implementations that recognize these addresses. I also believe that it is apporpriate for the node requirements document to indicate the minimal acceptable support that a node should have for site-local unicast addressing. In my opinion, we should limit the use of unicast site-local addresses to non-globally connected sites, and have the following requirements for IPv6 nodes: - Hosts do not have to be aware of site-local addresses at all (treat them just like globals). - Routers do not have to be aware of site-local addresses at all (treat them just like globals). I do understand that, even if we do make this restriction, there may be some people in the world who will later insist on using site-local addresses (or other allocated private addresses) to build a private address space within a globally connected IPv6 network. I also understand that those people may build a kludge tower to support this, similar to the IPv4 kludge tower needed to support NAT, but with the added twist that a single node may have both private and global addresses (yum!). However, I don't think that the IPv6 WG should go down the rat-hole of documenting that kludge tower... Instead, I think that we should advocate a position where all nodes on globally attached networks have global addresses, and site-local addresses are only used on non-globally connected networks. This would work with the currently documented IPv6 routing protocols, would provide the easiest IPv4->IPv6 transition for applications, and would not require changes to DNS. This also has the advantage of limiting the problem that the IPv6 WG is trying to solve, which should allow us to finish up the base IPv6 documents and confidently deploy IPv6. In my opinion, IPv6 does not require support for private site-local unicast address spaces to be successful. The major benefits of IPv6 are a larger address space (which should eliminate some motivations for using private address spaces) and host autoconfiguration, and I think that the world is already preparing to deploy IPv6 based on those current advantages. I _would_ support an effort to start a separate IRTF or IETF WG to explore whether we can build an architecturally sound model for private and global addresses to co-exist on the same network and in the same nodes, but I would prefer not to invent that model in the IPv6 WG and build it into the core of IPv6. This is my personal opinion, not a directive from the chairs or anything like that. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 13:04:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PK4V29028185; Fri, 25 Oct 2002 13:04:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PK4Ve1028184; Fri, 25 Oct 2002 13:04:31 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PK4N29028177 for ; Fri, 25 Oct 2002 13:04:28 -0700 (PDT) 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 g9PK4VMq013706 for ; Fri, 25 Oct 2002 13:04:31 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07971 for ; Fri, 25 Oct 2002 14:04:25 -0600 (MDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9PK4Nux026088 for ; Fri, 25 Oct 2002 16:04:25 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 25 Oct 2002 16:04:07 -0400 Message-ID: <3DB9A331.5050409@nc.rr.com> Date: Fri, 25 Oct 2002 16:01:53 -0400 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: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 References: <200210241502.g9OF2e014626@astro.cs.utk.edu> <(Your message of "Thu, 24 Oct 2002 14:14:40 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.nokia.com> <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Margaret Wasserman wrote: > At 12:17 PM 10/24/02, Margaret Wasserman wrote: > >> I think that we should keep site-local addresses in the >> addressing architecture, but limit their use to non-globally- >> connected IPv6 networks. > > > Some folks have pointed out that it might have been helpful if > I had explained my reasoning... > > The addressing architecture currently defines a set of addresses > that are allocated for use as "site-local unicast addresses", but > it does not discuss the details of when or how those addresses can > or should be used. This is fine with me. > > The scoped addressing architecture document defines how site-local > unicast addresses (and other scoped addresses) will be used, and > defines node behaviour related to these addresses. I am suggesting > that we should consider placing some restrictions on the _use_ > of site-local addresses in the scoped addressing architecture > document. I agree. > > However, it is imperative that the site-local address allocation > remain in the addressing architecture, even if we do decide that > the use of these addresses should be restricted (or even forbidden). > The allocation has been there for several years, and there are some > implementations that recognize these addresses. Yes. > > I also believe that it is apporpriate for the node requirements > document to indicate the minimal acceptable support that a node > should have for site-local unicast addressing. > > In my opinion, we should limit the use of unicast site-local > addresses to non-globally connected sites, and have the following > requirements for IPv6 nodes: > > - Hosts do not have to be aware of site-local addresses > at all (treat them just like globals). > - Routers do not have to be aware of site-local > addresses at all (treat them just like globals). May I suggest that this behavior MUST be the default? That way, an administrator has to make a conscious decision to enable the multi-sited feature. > > I do understand that, even if we do make this restriction, there may > be some people in the world who will later insist on using site-local > addresses (or other allocated private addresses) to build > a private address space within a globally connected IPv6 network. > I also understand that those people may build a kludge tower to > support this, similar to the IPv4 kludge tower needed to support > NAT, but with the added twist that a single node may have both > private and global addresses (yum!). However, I don't think that > the IPv6 WG should go down the rat-hole of documenting that kludge > tower... Completely agree. > > Instead, I think that we should advocate a position where all > nodes on globally attached networks have global addresses, and > site-local addresses are only used on non-globally connected > networks. This would work with the currently documented IPv6 > routing protocols, would provide the easiest IPv4->IPv6 transition > for applications, and would not require changes to DNS. This also > has the advantage of limiting the problem that the IPv6 WG is trying > to solve, which should allow us to finish up the base IPv6 documents > and confidently deploy IPv6. Good. > > In my opinion, IPv6 does not require support for private > site-local unicast address spaces to be successful. The major > benefits of IPv6 are a larger address space (which should eliminate > some motivations for using private address spaces) and host > autoconfiguration, and I think that the world is already preparing > to deploy IPv6 based on those current advantages. I would like to re-iterate that v6 does not need site-local addresses to be successful. To me, the benefit does not come close to outweighing the cost. > > I _would_ support an effort to start a separate IRTF or IETF WG > to explore whether we can build an architecturally sound model for > private and global addresses to co-exist on the same network > and in the same nodes, but I would prefer not to invent that > model in the IPv6 WG and build it into the core of IPv6. Sounds reasonable to me. > > This is my personal opinion, not a directive from the chairs or > anything like that. So, the synopsis is: 1. FE80::/10 allocation stays in addr arch 2. Text is added to the node reqs specifying single-site behavior as the default 3. Text is added to the scoped addr arch to clearly define the use case for scoped addresses What about text clarifying the issue with multi-link subnets in addr arch? 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 Oct 25 13:29:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PKT829028316; Fri, 25 Oct 2002 13:29:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PKT812028315; Fri, 25 Oct 2002 13:29:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PKT429028308 for ; Fri, 25 Oct 2002 13:29:04 -0700 (PDT) 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 g9PKTDbB021944 for ; Fri, 25 Oct 2002 13:29:13 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27598 for ; Fri, 25 Oct 2002 13:29:08 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.46.218]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA11886; Fri, 25 Oct 2002 13:29:03 -0700 (PDT) Message-Id: <5.1.0.14.2.20021025162532.04332ce0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Oct 2002 16:30:31 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DB9A331.5050409@nc.rr.com> References: <200210241502.g9OF2e014626@astro.cs.utk.edu> <(Your message of "Thu, 24 Oct 2002 14:14:40 +0300.") <0C1353ABB1DEB74DB067ADFF749C4EEF015A5987@esebe004.ntc.nokia.com> <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >So, the synopsis is: > > 1. FE80::/10 allocation stays in addr arch > 2. Text is added to the node reqs specifying single-site > behavior as the default > 3. Text is added to the scoped addr arch to clearly define > the use case for scoped addresses Yes, that sounds right to me. With my added recommendation that the use case for site-local should be to use them only on non-globally connected networks. >What about text clarifying the issue with multi-link subnets in >addr arch? Bob has already submitted a new draft that removes the subnet-local multicast code point and returns it to unspecified, as he proposed on the list a week or two ago. This resolved Rob Austein's objection, and I don't think that anyone on the list objected to the change. If/when a proposal for multi-link subnets is adopted, that proposal can define an appropriate multicast code point (if desired) and define its use. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 13:33:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PKXK29028355; Fri, 25 Oct 2002 13:33:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PKXKuk028354; Fri, 25 Oct 2002 13:33:20 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PKXF29028344 for ; Fri, 25 Oct 2002 13:33:15 -0700 (PDT) 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 g9PKXOMq022071 for ; Fri, 25 Oct 2002 13:33:24 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06730 for ; Fri, 25 Oct 2002 14:33:18 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PKXG022524; Fri, 25 Oct 2002 16:33:16 -0400 (EDT) Message-Id: <200210252033.g9PKXG022524@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steven Blake cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "25 Oct 2002 16:08:16 -0300.") <1035572897.24814.110.camel@newcastle.torrentnet.com> Date: Fri, 25 Oct 2002 16:33:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site locals as defined in draft-ietf-ipngwg-addr-arch-v3-10.txt are > functionally no different than RFC 1918 addresses for IPv4. RFC 1918 addresses are intended only for isolated networks, with the only connections to the outside world to be provided by application level gateways. > Long term, less chaos will result if a block of addresses is set aside > as "unregulated spectrum" than if folks start configuring prefixes out > of the ~73% of the address space that is currently unassigned. It's not at all clear that RFC 1918 lessened the chaos caused by NAT. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 14:55:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PLtC29028583; Fri, 25 Oct 2002 14:55:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PLtCPl028582; Fri, 25 Oct 2002 14:55:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PLt829028575 for ; Fri, 25 Oct 2002 14:55:08 -0700 (PDT) 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 g9PLtGbB016344 for ; Fri, 25 Oct 2002 14:55:16 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21539 for ; Fri, 25 Oct 2002 15:55:10 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9PLt6023168; Fri, 25 Oct 2002 17:55:06 -0400 (EDT) Message-Id: <200210252155.g9PLt6023168@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Fri, 25 Oct 2002 15:40:30 EDT.") <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> Date: Fri, 25 Oct 2002 17:55:06 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At 12:17 PM 10/24/02, Margaret Wasserman wrote: > > >I think that we should keep site-local addresses in the > >addressing architecture, but limit their use to non-globally- > >connected IPv6 networks. > > Some folks have pointed out that it might have been helpful if > I had explained my reasoning... > > The addressing architecture currently defines a set of addresses > that are allocated for use as "site-local unicast addresses", but > it does not discuss the details of when or how those addresses can > or should be used. > > The scoped addressing architecture document defines how site-local > unicast addresses (and other scoped addresses) will be used, and > defines node behaviour related to these addresses. I am suggesting > that we should consider placing some restrictions on the _use_ > of site-local addresses in the scoped addressing architecture > document. that sounds reasonable. at least we should say that site-locals cause problems for some kinds of applications, we don't have good solutions to those problems yet, and we discourage use of site-locals until such problems are solved - and even then we don't know how well they will work with apps that aren't aware of SLs. IMHO we should also make similar statements about link-locals. > However, it is imperative that the site-local address allocation > remain in the addressing architecture, even if we do decide that > the use of these addresses should be restricted (or even forbidden). > The allocation has been there for several years, and there are some > implementations that recognize these addresses. I certainly don't want to make SL addresses available for other uses - having them be labelled 'reserved for site-local use if we ever figure out how to use them sanely' makes sense to me. > I also believe that it is apporpriate for the node requirements > document to indicate the minimal acceptable support that a node > should have for site-local unicast addressing. > > In my opinion, we should limit the use of unicast site-local > addresses to non-globally connected sites, I think we should limit them to sites that aren't connected to other IP networks using IP. If host H1 is on a network N1 that uses site-locals, and host H2 is on a network N2 that connects to both N1 and the public Internet, then an app that employs both H1 and H2 and perhaps other hosts on the Internet will have problems dealing with SL addresses from N1. > and have the following > requirements for IPv6 nodes: > > - Hosts do not have to be aware of site-local addresses > at all (treat them just like globals). > - Routers do not have to be aware of site-local > addresses at all (treat them just like globals). also: Applications should not have to be aware of SL addresses at all (just treat them like globals). > I do understand that, even if we do make this restriction, there may > be some people in the world who will later insist on using site-local > addresses (or other allocated private addresses) to build > a private address space within a globally connected IPv6 network. > I also understand that those people may build a kludge tower to > support this, similar to the IPv4 kludge tower needed to support > NAT, but with the added twist that a single node may have both > private and global addresses (yum!). However, I don't think that > the IPv6 WG should go down the rat-hole of documenting that kludge > tower... right. and we would do well to discourage that kludge tower, and also to identify better ways to solve the problems that the kludge tower was attempting to solve - easy renumbering (IPv6 is better but we're not there yet), efficient access via multiple providers (there are lots of limitations with advertising multiple prefixes), security, privacy, ease of configuration, etc. > Instead, I think that we should advocate a position where all > nodes on globally attached networks have global addresses, and > site-local addresses are only used on non-globally connected > networks. I don't think that's sufficient. We need for all nodes on all non-isolated networks to have global addresses. It's becoming increasingly common for private networks to interconnect to other networks which may or may not be attached to the public Internet. We need for applications to be able to cope with operating across both private and public networks. That doesn't mean that such applications should route data between private networks and the public internet or between private networks that don't explicitly connect to one another, (e.g. the app shouldn't try to circunvent access controls). on the contrary, the app should be able to trust the addresses to be globally unique and to trust the network to be able to route packets from any source to any destination if the network's policy permits. unless the app is explicitly configured to do otherwise (as in a proxy that permits limited access across a firewall), it shouldn't have to build its own addressing and routing system. > This would work with the currently documented IPv6 > routing protocols, would provide the easiest IPv4->IPv6 transition > for applications, and would not require changes to DNS. This also > has the advantage of limiting the problem that the IPv6 WG is trying > to solve, which should allow us to finish up the base IPv6 documents > and confidently deploy IPv6. > > In my opinion, IPv6 does not require support for private > site-local unicast address spaces to be successful. The major > benefits of IPv6 are a larger address space (which should eliminate > some motivations for using private address spaces) and host > autoconfiguration, and I think that the world is already preparing > to deploy IPv6 based on those current advantages. > > I _would_ support an effort to start a separate IRTF or IETF WG > to explore whether we can build an architecturally sound model for > private and global addresses to co-exist on the same network > and in the same nodes, but I would prefer not to invent that > model in the IPv6 WG and build it into the core of IPv6. sounds reasonable, provided such a WG or RT were populated with a healthy balance of layer 3 and layer 7 folks. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 16:01:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PN1W29028866; Fri, 25 Oct 2002 16:01:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PN1WEB028865; Fri, 25 Oct 2002 16:01:32 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PN1T29028858 for ; Fri, 25 Oct 2002 16:01:29 -0700 (PDT) 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 g9PN1cMq003791 for ; Fri, 25 Oct 2002 16:01:38 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12358 for ; Fri, 25 Oct 2002 16:01:32 -0700 (PDT) Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9PN1TxF019795 for ; Fri, 25 Oct 2002 16:01:29 -0700 (PDT) Received: from CDS-W2K2.cisco.com (dhcp-171-71-49-113.cisco.com [171.71.49.113]) by mira-sjcd-1.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ38797; Fri, 25 Oct 2002 16:02:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20021025153829.02badb10@andiamo.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Oct 2002 15:59:11 -0700 To: ipng@sunroof.eng.sun.com From: Claudio DeSanti Subject: I-D ACTION:draft-desanti-ipv6-over-fibre-channel-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new IPv6 over draft is available, regarding Fibre Channel. I would like to receive comments on it, on its technical content and whether it can be considered as a Working Group document. Thanks, Claudio. ---------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 over Fibre Channel Author(s) : C. DeSanti Filename : draft-desanti-ipv6-over-fibre-channel-00.txt Pages : 16 Date : 2002-10-21 Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and IPv4, as specified in [IP-FC]. The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 16:49:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PNne29028989; Fri, 25 Oct 2002 16:49:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9PNnefj028988; Fri, 25 Oct 2002 16:49:40 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9PNnb29028981 for ; Fri, 25 Oct 2002 16:49:37 -0700 (PDT) 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 g9PNnjMq016098 for ; Fri, 25 Oct 2002 16:49:45 -0700 (PDT) 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 RAA21132 for ; Fri, 25 Oct 2002 17:49:38 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 042E68D7; Fri, 25 Oct 2002 19:49:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Oct 2002 19:49:30 -0400 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: Node Requirements Issue 3 Date: Fri, 25 Oct 2002 19:49:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE96E9@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ8X5RaiNpFebIUSlqsFOTlPtz22QAIVBng From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 25 Oct 2002 23:49:30.0858 (UTC) FILETIME=[297E8CA0:01C27C81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9PNnb29028982 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this is a reasonable proposal. With these guidelines stated somewhere it will prevent most problems. But in routing code I would as implementor check if a site came in at me and if globally connected drop the packet and not let thru default route. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, October 25, 2002 3:41 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: Node Requirements Issue 3 > > > At 12:17 PM 10/24/02, Margaret Wasserman wrote: > > >I think that we should keep site-local addresses in the addressing > >architecture, but limit their use to non-globally- connected IPv6 > >networks. > > Some folks have pointed out that it might have been helpful > if I had explained my reasoning... > > The addressing architecture currently defines a set of > addresses that are allocated for use as "site-local unicast > addresses", but it does not discuss the details of when or > how those addresses can or should be used. > > The scoped addressing architecture document defines how > site-local unicast addresses (and other scoped addresses) > will be used, and defines node behaviour related to these > addresses. I am suggesting that we should consider placing > some restrictions on the _use_ of site-local addresses in the > scoped addressing architecture document. > > However, it is imperative that the site-local address > allocation remain in the addressing architecture, even if we > do decide that the use of these addresses should be > restricted (or even forbidden). The allocation has been there > for several years, and there are some implementations that > recognize these addresses. > > I also believe that it is apporpriate for the node > requirements document to indicate the minimal acceptable > support that a node should have for site-local unicast addressing. > > In my opinion, we should limit the use of unicast site-local > addresses to non-globally connected sites, and have the > following requirements for IPv6 nodes: > > - Hosts do not have to be aware of site-local addresses > at all (treat them just like globals). > - Routers do not have to be aware of site-local > addresses at all (treat them just like globals). > > I do understand that, even if we do make this restriction, > there may be some people in the world who will later insist > on using site-local addresses (or other allocated private > addresses) to build a private address space within a globally > connected IPv6 network. I also understand that those people > may build a kludge tower to support this, similar to the IPv4 > kludge tower needed to support NAT, but with the added twist > that a single node may have both private and global addresses > (yum!). However, I don't think that the IPv6 WG should go > down the rat-hole of documenting that kludge tower... > > Instead, I think that we should advocate a position where all > nodes on globally attached networks have global addresses, > and site-local addresses are only used on non-globally > connected networks. This would work with the currently > documented IPv6 routing protocols, would provide the easiest > IPv4->IPv6 transition for applications, and would not require > changes to DNS. This also has the advantage of limiting the > problem that the IPv6 WG is trying to solve, which should > allow us to finish up the base IPv6 documents and confidently > deploy IPv6. > > In my opinion, IPv6 does not require support for private > site-local unicast address spaces to be successful. The > major benefits of IPv6 are a larger address space (which > should eliminate some motivations for using private address > spaces) and host autoconfiguration, and I think that the > world is already preparing to deploy IPv6 based on those > current advantages. > > I _would_ support an effort to start a separate IRTF or IETF > WG to explore whether we can build an architecturally sound > model for private and global addresses to co-exist on the > same network and in the same nodes, but I would prefer not to > invent that model in the IPv6 WG and build it into the core of IPv6. > > This is my personal opinion, not a directive from the chairs > or anything like that. > > Margaret > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 22:14:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q5E229029583; Fri, 25 Oct 2002 22:14:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9Q5E26a029582; Fri, 25 Oct 2002 22:14:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q5Dx29029575 for ; Fri, 25 Oct 2002 22:13:59 -0700 (PDT) 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 g9Q5E6bB005694 for ; Fri, 25 Oct 2002 22:14:07 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14195 for ; Fri, 25 Oct 2002 23:14:00 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9Q5Drq03933; Sat, 26 Oct 2002 08:13:53 +0300 Date: Sat, 26 Oct 2002 08:13:52 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Margaret Wasserman , Subject: RE: Node Requirements Issue 3 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE96E9@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 25 Oct 2002, Bound, Jim wrote: > I think this is a reasonable proposal. With these guidelines stated > somewhere it will prevent most problems. Agree. > But in routing code I would as > implementor check if a site came in at me and if globally connected drop > the packet and not let thru default route. This would be relatively easy to do, I suppose. But note that there is (currently) more than that: site-border routers must also check source addresses of packets and drop them. This may get difficult as you have to have a way of configuring the fact that this is indeed a site border. This can't really be solved by adding a route.. (Note I meant site/global border with site border above, not two different sites) > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: Friday, October 25, 2002 3:41 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: Node Requirements Issue 3 > > > > > > At 12:17 PM 10/24/02, Margaret Wasserman wrote: > > > > >I think that we should keep site-local addresses in the addressing > > >architecture, but limit their use to non-globally- connected IPv6 > > >networks. > > > > Some folks have pointed out that it might have been helpful > > if I had explained my reasoning... > > > > The addressing architecture currently defines a set of > > addresses that are allocated for use as "site-local unicast > > addresses", but it does not discuss the details of when or > > how those addresses can or should be used. > > > > The scoped addressing architecture document defines how > > site-local unicast addresses (and other scoped addresses) > > will be used, and defines node behaviour related to these > > addresses. I am suggesting that we should consider placing > > some restrictions on the _use_ of site-local addresses in the > > scoped addressing architecture document. > > > > However, it is imperative that the site-local address > > allocation remain in the addressing architecture, even if we > > do decide that the use of these addresses should be > > restricted (or even forbidden). The allocation has been there > > for several years, and there are some implementations that > > recognize these addresses. > > > > I also believe that it is apporpriate for the node > > requirements document to indicate the minimal acceptable > > support that a node should have for site-local unicast addressing. > > > > In my opinion, we should limit the use of unicast site-local > > addresses to non-globally connected sites, and have the > > following requirements for IPv6 nodes: > > > > - Hosts do not have to be aware of site-local addresses > > at all (treat them just like globals). > > - Routers do not have to be aware of site-local > > addresses at all (treat them just like globals). > > > > I do understand that, even if we do make this restriction, > > there may be some people in the world who will later insist > > on using site-local addresses (or other allocated private > > addresses) to build a private address space within a globally > > connected IPv6 network. I also understand that those people > > may build a kludge tower to support this, similar to the IPv4 > > kludge tower needed to support NAT, but with the added twist > > that a single node may have both private and global addresses > > (yum!). However, I don't think that the IPv6 WG should go > > down the rat-hole of documenting that kludge tower... > > > > Instead, I think that we should advocate a position where all > > nodes on globally attached networks have global addresses, > > and site-local addresses are only used on non-globally > > connected networks. This would work with the currently > > documented IPv6 routing protocols, would provide the easiest > > IPv4->IPv6 transition for applications, and would not require > > changes to DNS. This also has the advantage of limiting the > > problem that the IPv6 WG is trying to solve, which should > > allow us to finish up the base IPv6 documents and confidently > > deploy IPv6. > > > > In my opinion, IPv6 does not require support for private > > site-local unicast address spaces to be successful. The > > major benefits of IPv6 are a larger address space (which > > should eliminate some motivations for using private address > > spaces) and host autoconfiguration, and I think that the > > world is already preparing to deploy IPv6 based on those > > current advantages. > > > > I _would_ support an effort to start a separate IRTF or IETF > > WG to explore whether we can build an architecturally sound > > model for private and global addresses to co-exist on the > > same network and in the same nodes, but I would prefer not to > > invent that model in the IPv6 WG and build it into the core of IPv6. > > > > This is my personal opinion, not a directive from the chairs > > or anything like that. > > > > Margaret > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 22:39:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q5dp29029692; Fri, 25 Oct 2002 22:39:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9Q5doNU029691; Fri, 25 Oct 2002 22:39:50 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q5dk29029684 for ; Fri, 25 Oct 2002 22:39:46 -0700 (PDT) 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 g9Q5dtMq013323 for ; Fri, 25 Oct 2002 22:39:55 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19989 for ; Fri, 25 Oct 2002 23:39:50 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4K00AG1QEC1D@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 25 Oct 2002 23:39:49 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4K00B2LQEAXJ@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 25 Oct 2002 23:39:47 -0600 (MDT) Date: Fri, 25 Oct 2002 22:40:07 -0700 From: Alain Durand Subject: Re: Node Requirements Issue 3 In-reply-to: <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Message-id: <62D680BE-E8A5-11D6-A2D7-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I think this is the right direction. Thank you for clarifying things. Also I support Keith point on limiting SL to sites that do not have a transitive connection to the Internet. - Alain. On Friday, October 25, 2002, at 12:40 PM, Margaret Wasserman wrote: > At 12:17 PM 10/24/02, Margaret Wasserman wrote: > >> I think that we should keep site-local addresses in the >> addressing architecture, but limit their use to non-globally- >> connected IPv6 networks. > > Some folks have pointed out that it might have been helpful if > I had explained my reasoning... > > The addressing architecture currently defines a set of addresses > that are allocated for use as "site-local unicast addresses", but > it does not discuss the details of when or how those addresses can > or should be used. > > The scoped addressing architecture document defines how site-local > unicast addresses (and other scoped addresses) will be used, and > defines node behaviour related to these addresses. I am suggesting > that we should consider placing some restrictions on the _use_ > of site-local addresses in the scoped addressing architecture > document. > > However, it is imperative that the site-local address allocation > remain in the addressing architecture, even if we do decide that > the use of these addresses should be restricted (or even forbidden). > The allocation has been there for several years, and there are some > implementations that recognize these addresses. > > I also believe that it is apporpriate for the node requirements > document to indicate the minimal acceptable support that a node > should have for site-local unicast addressing. > > In my opinion, we should limit the use of unicast site-local > addresses to non-globally connected sites, and have the following > requirements for IPv6 nodes: > > - Hosts do not have to be aware of site-local addresses > at all (treat them just like globals). > - Routers do not have to be aware of site-local > addresses at all (treat them just like globals). > > I do understand that, even if we do make this restriction, there may > be some people in the world who will later insist on using site-local > addresses (or other allocated private addresses) to build > a private address space within a globally connected IPv6 network. > I also understand that those people may build a kludge tower to > support this, similar to the IPv4 kludge tower needed to support > NAT, but with the added twist that a single node may have both > private and global addresses (yum!). However, I don't think that > the IPv6 WG should go down the rat-hole of documenting that kludge > tower... > > Instead, I think that we should advocate a position where all > nodes on globally attached networks have global addresses, and > site-local addresses are only used on non-globally connected > networks. This would work with the currently documented IPv6 > routing protocols, would provide the easiest IPv4->IPv6 transition > for applications, and would not require changes to DNS. This also > has the advantage of limiting the problem that the IPv6 WG is trying > to solve, which should allow us to finish up the base IPv6 documents > and confidently deploy IPv6. > > In my opinion, IPv6 does not require support for private > site-local unicast address spaces to be successful. The major > benefits of IPv6 are a larger address space (which should eliminate > some motivations for using private address spaces) and host > autoconfiguration, and I think that the world is already preparing > to deploy IPv6 based on those current advantages. > > I _would_ support an effort to start a separate IRTF or IETF WG > to explore whether we can build an architecturally sound model for > private and global addresses to co-exist on the same network > and in the same nodes, but I would prefer not to invent that > model in the IPv6 WG and build it into the core of IPv6. > > This is my personal opinion, not a directive from the chairs or > anything like that. > > Margaret > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 25 23:17:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q6He29029799; Fri, 25 Oct 2002 23:17:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9Q6HevJ029798; Fri, 25 Oct 2002 23:17:40 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9Q6Hb29029791 for ; Fri, 25 Oct 2002 23:17:37 -0700 (PDT) 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 g9Q6HjMq016792 for ; Fri, 25 Oct 2002 23:17:45 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA18252 for ; Fri, 25 Oct 2002 23:17:39 -0700 (PDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 75B3F18E2 for ; Sat, 26 Oct 2002 02:17:38 -0400 (EDT) Date: Sat, 26 Oct 2002 02:17:38 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 (site-local addresses) In-Reply-To: <5.1.0.14.2.20021025151737.0432fe20@mail.windriver.com> References: <200210241502.g9OF2e014626@astro.cs.utk.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021026061738.75B3F18E2@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that Margaret's proposal on site-local addresses makes a lot of sense, and I think it's the best suggestion I've heard to date for how we should move forward from where we are now on this issue. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 26 09:58:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9QGwl29000877; Sat, 26 Oct 2002 09:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9QGwloq000876; Sat, 26 Oct 2002 09:58:47 -0700 (PDT) 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9QGwi29000869 for ; Sat, 26 Oct 2002 09:58:44 -0700 (PDT) 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 g9QGwqMq025674 for ; Sat, 26 Oct 2002 09:58:52 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04405 for ; Sat, 26 Oct 2002 10:58:43 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8C36C4119; Sat, 26 Oct 2002 12:58:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 26 Oct 2002 12:58:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27D10.EFFC1D18" Subject: RE: Node Requirements Issue 3 Date: Sat, 26 Oct 2002 12:58:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9710@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ8rn27UjnqWeoEQr6rHU0HbprtTAAXqfmA From: "Bound, Jim" To: "Pekka Savola" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 26 Oct 2002 16:58:42.0334 (UTC) FILETIME=[F03E03E0:01C27D10] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C27D10.EFFC1D18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > But in routing code I would as > > implementor check if a site came in at me and if globally connected > > drop the packet and not let thru default route. > > This would be relatively easy to do, I suppose Yes but I believe we need this in products quickly if we support Margarets rule which I do and can it be done as download rule upgrade to existing routers or will it have to be put in slow path. > > But note that there is (currently) more than that: > site-border routers > must also check source addresses of packets and drop them. =20 > This may get > difficult as you have to have a way of configuring the fact > that this is > indeed a site border. This can't really be solved by adding a route.. It is a compare and XOR operation on the address at the ingress point. If we apply Margarets rule-set which I support a site border router would only be dealing with site locals if it had no connectivity to non-site communications. So I don't see that problem per compliance. But to prevent errors the site routers could do the fix I state above as easily as ingress/egress border routers to a site from a public or private ISP. > > (Note I meant site/global border with site border above, not two > different sites) This is a good point to question. My read of Margarets rule is that the border router would not be configured to see a site on any interface? The only reason to do what I say above is insurance for the network operations community in the product implementation. /jim ------_=_NextPart_001_01C27D10.EFFC1D18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

> > But in routing code I would as
> >=20 implementor check if a site came in at me and if globally = connected
> >=20 drop the packet and not let thru default route.
>
> This = would be=20 relatively easy to do, I suppose

Yes but I believe we need this in products quickly if = we support=20 Margarets rule which I do and can it be done as download rule upgrade to = existing routers or will it have to be put in slow path.


>
> But note that there is (currently) = more than=20 that:
> site-border routers
> must also check source = addresses of=20 packets and drop them.  
> This may get
> = difficult as you=20 have to have a way of configuring the fact
> that this is
> = indeed a=20 site border.  This can't really be solved by adding a = route..

It is=20 a compare and XOR operation on the address at the ingress point. If we = apply=20 Margarets rule-set which I support a site border router would only be = dealing=20 with site locals if it had no connectivity to non-site communications. = So I=20 don't see that problem per compliance. But to prevent errors the site = routers=20 could do the fix I state above as easily as ingress/egress border = routers to a=20 site from a public or private ISP.

>
> (Note I meant = site/global=20 border with site border above, not two
> different = sites)

This is a=20 good point to question. My read of Margarets rule is that the border = router=20 would not be configured to see a site on any interface?  The only = reason to=20 do what I say above is insurance for the network operations community in = the=20 product implementation.

/jim

=00 ------_=_NextPart_001_01C27D10.EFFC1D18-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 04:18:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCIM29002784; Sun, 27 Oct 2002 04:18:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCILG8002783; Sun, 27 Oct 2002 04:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCII29002776 for ; Sun, 27 Oct 2002 04:18:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9RCIRbB020375 for ; Sun, 27 Oct 2002 04:18:27 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15889 for ; Sun, 27 Oct 2002 05:18:21 -0700 (MST) 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 g9RCIZB23573 for ; Sun, 27 Oct 2002 14:18:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:18:19 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:18:18 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:18:18 +0200 content-class: urn:content-classes:message Subject: Node Requirements Issues 4, 5, & 6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:18:17 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANt2m3A= To: X-OriginalArrivalTime: 27 Oct 2002 12:18:18.0241 (UTC) FILETIME=[EEB6E710:01C27DB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCIJ29002777 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Recently all of these issues have been discussed on the list, and I wanted to check if any of these have implication on the node requirements: 4) Some issues that have come-up during Address Scoping discussion. 5) Anything needed to be captured Address Architecture document implications 6) Default Address Selection level of support. I have gotten a number of private mails saying that Default Address Selection should not be mandatory. What is the list's view? 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 Sun Oct 27 04:19:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCJv29002823; Sun, 27 Oct 2002 04:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCJvAQ002822; Sun, 27 Oct 2002 04:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCJs29002815 for ; Sun, 27 Oct 2002 04:19:54 -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 g9RCK2Mq023782 for ; Sun, 27 Oct 2002 04:20:02 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15124 for ; Sun, 27 Oct 2002 05:19:56 -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 g9RCJXb24531 for ; Sun, 27 Oct 2002 14:19:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:19:55 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:19:53 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:19:52 +0200 content-class: urn:content-classes:message Subject: Node Requirements Issue 7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:19:51 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANuQJJA= To: X-OriginalArrivalTime: 27 Oct 2002 12:19:52.0496 (UTC) FILETIME=[26E51300:01C27DB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCJs29002816 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Issue 7 is: 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? Brian Haberman said: Given that new layer-2 technologies will appear and future docs may/will define how IPv6 runs over those layers, I would suggest using generic text that says that if a vendor wants to support IPv6 over a particular L2, then they must implement the IPv6-over-foo spec for that L2. Then I would give a few examples (IPv6-over-ethernet, etc.). I agree, what does the list think? 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 Sun Oct 27 04:23:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCNa29002859; Sun, 27 Oct 2002 04:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCNaOY002858; Sun, 27 Oct 2002 04:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCNX29002851 for ; Sun, 27 Oct 2002 04:23:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9RCNfbB020719 for ; Sun, 27 Oct 2002 04:23:41 -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 FAA16360 for ; Sun, 27 Oct 2002 05:23:35 -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 g9RCNCb25097 for ; Sun, 27 Oct 2002 14:23:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:23:33 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:23:32 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:23:32 +0200 content-class: urn:content-classes:message Subject: Node Requirements issue 8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:23:31 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements status Thread-Index: AcJ6iOwd4Xuthmk8QeSP8gOOukuCdgDKkSOg To: X-OriginalArrivalTime: 27 Oct 2002 12:23:32.0595 (UTC) FILETIME=[AA158430:01C27DB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCNX29002852 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, 8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? The design team has waviered over DNS. Some say a strong SHOULD is enough, others say it is a MUST. What does this list feel? Should some level of DNS discovery / configuration be mandatory if DNS is used? I guess manual configuration would be a MUST in that case. The on-going DNS discovery issue still is yet to be completed, but could we mention something in the draft+ Also, what about DHCPv6? Is it mandatory, if so what are the madatory components, etc. Should it be mandatory for all types of devices? I think a SHOULD or MAY, with some detail may be sufficient. best regards, 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 Sun Oct 27 04:25:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCPN29002901; Sun, 27 Oct 2002 04:25:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCPN2u002900; Sun, 27 Oct 2002 04:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCPK29002893 for ; Sun, 27 Oct 2002 04:25:20 -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 g9RCPTMq024200 for ; Sun, 27 Oct 2002 04:25:29 -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 FAA16789 for ; Sun, 27 Oct 2002 05:25:23 -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 g9RCP0b25374 for ; Sun, 27 Oct 2002 14:25:00 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:25:22 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:25:21 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:25:21 +0200 content-class: urn:content-classes:message Subject: Node Requirements Issue 9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:25:21 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANu96NA= To: X-OriginalArrivalTime: 27 Oct 2002 12:25:21.0559 (UTC) FILETIME=[EB081A70:01C27DB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCPK29002894 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, 9) Are Transition mechanisms mandatory; is support for IPv4 mandatory? I think that IPv4 is not mandatory, but a strong SHOULD. If IPv4 is supported, then some sort of transition mechanism is madatory - anyone have suggestions on what should be mandatory? Text suggestions are helpful. 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 Sun Oct 27 04:26:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCQ529002921; Sun, 27 Oct 2002 04:26:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCQ5qA002920; Sun, 27 Oct 2002 04:26:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCQ129002913 for ; Sun, 27 Oct 2002 04:26: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 g9RCQ9bB020939 for ; Sun, 27 Oct 2002 04:26:09 -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 FAA06997 for ; Sun, 27 Oct 2002 05:25:59 -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 g9RCPab25447 for ; Sun, 27 Oct 2002 14:25:36 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:25:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:25:57 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:25:57 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:25:56 +0200 content-class: urn:content-classes:message Subject: Node Requirements issue 10 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:25:56 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANvOXVA= To: , X-OriginalArrivalTime: 27 Oct 2002 12:25:57.0080 (UTC) FILETIME=[00342D80:01C27DB4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCQ129002914 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, 10) What level of detail is needed for MIBs in the document? Please suggest text. 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 Sun Oct 27 04:27:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCRm29002991; Sun, 27 Oct 2002 04:27:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RCRmj3002990; Sun, 27 Oct 2002 04:27:48 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RCRi29002977 for ; Sun, 27 Oct 2002 04:27:45 -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 g9RCRrMq024413 for ; Sun, 27 Oct 2002 04:27:53 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16984 for ; Sun, 27 Oct 2002 05:27:46 -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 g9RCRNb25688 for ; Sun, 27 Oct 2002 14:27:23 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 27 Oct 2002 14:27:44 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:27:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 27 Oct 2002 14:27:44 +0200 content-class: urn:content-classes:message Subject: Node Requirements issue 10 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 27 Oct 2002 14:27:44 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: Re: [mobile-ip] Issue 88 proposal for resolution] Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANvONSA= To: X-OriginalArrivalTime: 27 Oct 2002 12:27:44.0616 (UTC) FILETIME=[404CDE80:01C27DB4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9RCRj29002978 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, 11) Requirements language (MUST/SHOULD/MAY, etc.) needs discussion. I have gotten the comment that: >In general are we planning to map "unconditional" and "conditional" >clauses into MAY/SHOULD/MUST etc. ? > >unconditionally mandatory --> MUST >conditionally mandatory --> MUST if the condition is true >conditionally optional ---> SHOULD >unconditionally optional ---> MAY It does not map exactly to SHOULD. SHOULD means that we recommend that one should implement this (but there might be reasons why one doesn't), where "conditionally optional" loses the recommendation part. I think I agree, and will make the change - however, this may cause some additional work in the future, to ensure that all of the requirement language usage makes sense for all types of devices, from servers to embedded stacks for lightbulbs. 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 Sun Oct 27 06:34:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REYN29003555; Sun, 27 Oct 2002 06:34:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9REYNGG003554; Sun, 27 Oct 2002 06:34:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REYK29003547 for ; Sun, 27 Oct 2002 06:34:20 -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 g9REYSbB000885 for ; Sun, 27 Oct 2002 06:34:28 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13800 for ; Sun, 27 Oct 2002 07:34:21 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7C9736A901; Sun, 27 Oct 2002 16:34:05 +0200 (EET) Message-ID: <3DBBF921.2060604@kolumbus.fi> Date: Sun, 27 Oct 2002 16:33:05 +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: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 7 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 all, > > Issue 7 is: > > 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? > > Brian Haberman said: > > Given that new layer-2 technologies will appear and future docs may/will > define how IPv6 runs over those layers, I would suggest using generic > text that says that if a vendor wants to support IPv6 over a particular > L2, then they must implement the IPv6-over-foo spec for that L2. Then > I would give a few examples (IPv6-over-ethernet, etc.). > > I agree, what does the list think? I understand that the list can't be complete. However, it would be useful to have the list of all current IPv6 over Foos as a reference. Also, there might be situations where there are multiple alternatives or the specification is missing, leading to confusion. So my suggestion is to include all the current IPv6 over Foos and then give Brian's rule as a catch-all at the end. 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 Sun Oct 27 06:46:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REkw29003606; Sun, 27 Oct 2002 06:46:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9REkwhv003605; Sun, 27 Oct 2002 06:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REks29003598 for ; Sun, 27 Oct 2002 06:46: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 g9REl2Mq009652 for ; Sun, 27 Oct 2002 06:47:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16425 for ; Sun, 27 Oct 2002 07:46:57 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9REkr000454; Sun, 27 Oct 2002 09:46:53 -0500 (EST) Message-Id: <200210271446.g9REkr000454@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issues 4, 5, & 6 In-reply-to: (Your message of "Sun, 27 Oct 2002 14:18:17 +0200.") Date: Sun, 27 Oct 2002 09:46:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have gotten a number of private mails saying that Default Address Selection > should not be mandatory. What is the list's view? I'm all for consistent behavior across implementations, but it's unrealistic to think that a single default set of rules will work for all or even most applications, in all or even most environments. no default address selection rule is going to be very useful by itself. to be useful something like the following are also needed: - some constraints on use of scoped addresses (as input to network designers/maintainers) - some constraints on address instability (as input to network designers/maintainers and app designers/implementors) - some ability for apps to input into the address selection algorithm what their needs are - e.g. is privacy more important than address stability? is there a need for this address to be globally usable? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 27 06:48:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REmU29003616; Sun, 27 Oct 2002 06:48:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9REmTi2003615; Sun, 27 Oct 2002 06:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9REmP29003608 for ; Sun, 27 Oct 2002 06:48:25 -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 g9REmXbB001890 for ; Sun, 27 Oct 2002 06:48:33 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12562 for ; Sun, 27 Oct 2002 06:48:28 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9REmP000475; Sun, 27 Oct 2002 09:48:25 -0500 (EST) Message-Id: <200210271448.g9REmP000475@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements issue 8 In-reply-to: (Your message of "Sun, 27 Oct 2002 14:23:31 +0200.") Date: Sun, 27 Oct 2002 09:48:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DNS should not be a MUST. not all applications need to use it. Also, DNS is a separate service from IP. IP should not be thought to be dependent on DNS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 08:55:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RGt229004177; Sun, 27 Oct 2002 08:55:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RGt1wv004176; Sun, 27 Oct 2002 08:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RGsw29004169 for ; Sun, 27 Oct 2002 08:54: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 g9RGt7bB013045 for ; Sun, 27 Oct 2002 08:55:07 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08192 for ; Sun, 27 Oct 2002 09:55:01 -0700 (MST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9RGt0PQ027424 for ; Sun, 27 Oct 2002 08:55:00 -0800 (PST) Date: Sun, 27 Oct 2002 11:55:00 -0500 (EST) From: Ralph Droms To: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements issue 8 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 We discussed the DHCPv6 issue at the v6ops meeting thsi past August. One observation about the requirement for DHCPv6 is the requirement for clarifying references to "stateful autoconfiguration" (SAAC): does SAAC == DHCPv6? Where does manual configuration fit? Related to the previous question is the requirement for clarification of the 'M' and 'O' bits: for example, does setting the 'O' bit mean that hosts MUST perform SAAC for "other configuration information", which (depending on the answer to the question "SAAC == DHCPv6") has an impact on the requirement for implication of DHCPv6. I have a draft that I expect to submit for publication later today that summarizes these questions and a couple of other isssues around DHCPv6 that we discussed in the v6ops WG meeting... - Ralph On Sun, 27 Oct 2002 john.loughney@nokia.com wrote: > Hi all, > > 8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? > > The design team has waviered over DNS. Some say a strong SHOULD is enough, > others say it is a MUST. What does this list feel? > > Should some level of DNS discovery / configuration be mandatory if DNS > is used? I guess manual configuration would be a MUST in that case. > The on-going DNS discovery issue still is yet to be completed, but could > we mention something in the draft+ > > Also, what about DHCPv6? Is it mandatory, if so what are the madatory > components, etc. Should it be mandatory for all types of devices? I think > a SHOULD or MAY, with some detail may be sufficient. > > best regards, > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 09:05:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5V29004260; Sun, 27 Oct 2002 09:05:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RH5Vjb004258; Sun, 27 Oct 2002 09:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5M29004238 for ; Sun, 27 Oct 2002 09:05:23 -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 g9RH5VbB014144 for ; Sun, 27 Oct 2002 09:05:31 -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 KAA23359 for ; Sun, 27 Oct 2002 10:05:25 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA28642; Sun, 27 Oct 2002 09:05:18 -0800 (PST) Message-Id: <5.1.0.14.2.20021027120134.029fc150@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Oct 2002 12:02:16 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: Re: Node Requirements Issue 9 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 don't know if we want to say that IPv6 nodes SHOULD implement IPv4... However, I do think it makes sense to have a section that includes additional requirements (if any) for dual-stack nodes. Margaret At 07:25 AM 10/27/02, john.loughney@nokia.com wrote: >Hi all, > >9) Are Transition mechanisms mandatory; is support for IPv4 mandatory? > >I think that IPv4 is not mandatory, but a strong SHOULD. If IPv4 >is supported, then some sort of transition mechanism is madatory - >anyone have suggestions on what should be mandatory? Text suggestions >are helpful. > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 09:05:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5W29004265; Sun, 27 Oct 2002 09:05:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RH5WoW004264; Sun, 27 Oct 2002 09:05:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5N29004247 for ; Sun, 27 Oct 2002 09:05: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 g9RH5WMq022469 for ; Sun, 27 Oct 2002 09:05:32 -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 KAA10330 for ; Sun, 27 Oct 2002 10:05:26 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA28649; Sun, 27 Oct 2002 09:05:19 -0800 (PST) Message-Id: <5.1.0.14.2.20021027120323.029faec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Oct 2002 12:06:42 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: Re: Node Requirements issue 8 Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:23 AM 10/27/02, john.loughney@nokia.com wrote: >Hi all, > >8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? These are actually three questions, I think. IMO, a DNS (resolver) is not a required feature of an IPv6 node (a MAY). There are plenty of IPv4 nodes that do not include a DNS resolver, and there will be plenty of IPv6 nodes that do not. Examples include printers, consumer products, industrial control equipment, parts of cars and airplanes, etc... There are many IPv4 nodes that never serve as "clients", and there will hopefully be even more IPv6 nodes in these types of roles. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 27 09:05:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5V29004261; Sun, 27 Oct 2002 09:05:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RH5VaE004259; Sun, 27 Oct 2002 09:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RH5M29004237 for ; Sun, 27 Oct 2002 09:05:23 -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 g9RH5VbB014143 for ; Sun, 27 Oct 2002 09:05:31 -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 KAA23358 for ; Sun, 27 Oct 2002 10:05:25 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA28629; Sun, 27 Oct 2002 09:05:15 -0800 (PST) Message-Id: <5.1.0.14.2.20021027120042.029fcd90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Oct 2002 12:00:50 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: Re: Node Requirements Issue 7 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 Sounds right to me. Margaret At 07:19 AM 10/27/02, john.loughney@nokia.com wrote: >Hi all, > >Issue 7 is: > > 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? > >Brian Haberman said: > > Given that new layer-2 technologies will appear and future docs may/will > define how IPv6 runs over those layers, I would suggest using generic > text that says that if a vendor wants to support IPv6 over a particular > L2, then they must implement the IPv6-over-foo spec for that L2. Then > I would give a few examples (IPv6-over-ethernet, etc.). > >I agree, what does the list think? > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 09:50:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RHoe29004555; Sun, 27 Oct 2002 09:50:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9RHoeVY004554; Sun, 27 Oct 2002 09:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9RHoa29004547 for ; Sun, 27 Oct 2002 09:50:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9RHoibB019042 for ; Sun, 27 Oct 2002 09:50:44 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08576 for ; Sun, 27 Oct 2002 10:50:38 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9RHoX001342; Sun, 27 Oct 2002 12:50:33 -0500 (EST) Message-Id: <200210271750.g9RHoX001342@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 9 In-reply-to: (Your message of "Sun, 27 Oct 2002 12:02:16 EST.") <5.1.0.14.2.20021027120134.029fc150@mail.windriver.com> Date: Sun, 27 Oct 2002 12:50:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know if we want to say that IPv6 nodes SHOULD implement > IPv4... However, I do think it makes sense to have a section > that includes additional requirements (if any) for dual-stack > nodes. I agree both that IPv6 nodes should probably not be required in any sense to implement IPv4, and also that it makes sense to ask whether there are any additional requirements for dual-stack hosts. Actually it might be worthwhile to consider three categories - native IPv6 only - native IPv6 with IPv4 supported only via tunneling over IPv6 - native IPv6 and native IPv4 both fully supported -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 17:18:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S1If29005526; Sun, 27 Oct 2002 17:18:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S1IfeK005525; Sun, 27 Oct 2002 17:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S1Ic29005518 for ; Sun, 27 Oct 2002 17:18: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 g9S1IkbB006076 for ; Sun, 27 Oct 2002 17:18:46 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10723 for ; Sun, 27 Oct 2002 18:18:40 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA03677; Sun, 27 Oct 2002 17:18:30 -0800 (PST) Message-Id: <5.1.0.14.2.20021027201851.025bf470@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Oct 2002 20:20:00 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Node Requirements Issue 3 Cc: "Keith Moore" , 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 Hi Rich, Could you elaborate a bit more? Are there particular problems that would be caused by limiting the use of site-local addresses to non-globally- connected networks? Margaret At 12:53 PM 10/24/02, Richard Draves wrote: >This is craziness. We (I don't mean just MS) have shipping >implementations that support site-locals. We have operational >deployments using site-locals. We have applications that work just fine >with site-locals. > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 27 18:55:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S2tJ29005688; Sun, 27 Oct 2002 18:55:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S2tJwn005687; Sun, 27 Oct 2002 18:55:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S2tF29005680 for ; Sun, 27 Oct 2002 18:55: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 g9S2tOMq029720 for ; Sun, 27 Oct 2002 18:55:24 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23672 for ; Sun, 27 Oct 2002 18:55:19 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA02175; Sun, 27 Oct 2002 18:55:10 -0800 (PST) Message-Id: <5.1.0.14.2.20021027215436.03335b70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Oct 2002 21:56:41 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Node Requirements Issue 3 Cc: "Roy Brabson" , 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 >For a multi-sited host, one additional requirement is that applications >should deal with sockaddrs instead of directly with addresses, so that >the scope-id is preserved & passed around as needed. Another additional >requirement is routing table lookup needs to be cognizant of scoping. When a multi-sited implementation gets site-local addresses from the DNS (assuming that it runs two-faced DNS and returns site-locals), how will the multi-sited host know which site the addresses are in? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 27 22:51:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S6pw29006380; Sun, 27 Oct 2002 22:51:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S6pvJl006379; Sun, 27 Oct 2002 22:51:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S6ps29006372 for ; Sun, 27 Oct 2002 22:51: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 g9S6pwMq024771 for ; Sun, 27 Oct 2002 22:51:59 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05223 for ; Sun, 27 Oct 2002 23:51:53 -0700 (MST) 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 g9S6q9B08044 for ; Mon, 28 Oct 2002 08:52:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Oct 2002 08:51:51 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:51:51 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:51:51 +0200 content-class: urn:content-classes:message Subject: RE: Node Requirements issue 8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 08:51:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements issue 8 Thread-Index: AcJ9x+kVBTx5RtUuSWuG+FmwVvuePwAhkvug To: Cc: X-OriginalArrivalTime: 28 Oct 2002 06:51:51.0209 (UTC) FILETIME=[7E58C190:01C27E4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9S6pt29006373 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > DNS should not be a MUST. not all applications need to use it. > Also, DNS is a separate service from IP. IP should not be > thought to be dependent on DNS. I tend to agree with you. I see the following options: 1) For IPv6 nodes, DNS is a MUST if applications require it. 2) For IPv6 nodes, support for DNS SHOULD be included, as many applications require it. 3) For IPv6 nodes, DNS SHOULD be included as DNS support is a 'good thing.' 4) For IPv6 nodes, DNS MAY be included. Any suggestions? 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 Sun Oct 27 22:53:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S6r829006397; Sun, 27 Oct 2002 22:53:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S6r7w4006396; Sun, 27 Oct 2002 22:53:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S6r429006389 for ; Sun, 27 Oct 2002 22:53:04 -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 g9S6rCbB010882 for ; Sun, 27 Oct 2002 22:53:13 -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 XAA05616 for ; Sun, 27 Oct 2002 23:53:06 -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 g9S6qhb13479 for ; Mon, 28 Oct 2002 08:52:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Oct 2002 08:53:05 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:53:05 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:53:04 +0200 content-class: urn:content-classes:message Subject: RE: Node Requirements Issue 9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 08:53:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 9 Thread-Index: AcJ94Vwvx4h8WquaQiac3ryc0HUOCgAbULSA To: , Cc: X-OriginalArrivalTime: 28 Oct 2002 06:53:05.0048 (UTC) FILETIME=[AA5BB180:01C27E4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9S6r429006390 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > > I don't know if we want to say that IPv6 nodes SHOULD implement > > IPv4... However, I do think it makes sense to have a section > > that includes additional requirements (if any) for dual-stack > > nodes. > > I agree both that IPv6 nodes should probably not be required in any > sense to implement IPv4, and also that it makes sense to ask whether > there are any additional requirements for dual-stack hosts. > > Actually it might be worthwhile to consider three categories > > - native IPv6 only > - native IPv6 with IPv4 supported only via tunneling over IPv6 > - native IPv6 and native IPv4 both fully supported Good point. I will try to capture this in the document. 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 Sun Oct 27 23:37:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S7b629006651; Sun, 27 Oct 2002 23:37:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S7b57K006650; Sun, 27 Oct 2002 23:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S7b229006643 for ; Sun, 27 Oct 2002 23:37:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9S7bBMq000393 for ; Sun, 27 Oct 2002 23:37:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12882 for ; Sun, 27 Oct 2002 23:37:05 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9S7apk29889; Mon, 28 Oct 2002 09:36:52 +0200 Date: Mon, 28 Oct 2002 09:36:51 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: Richard Draves , Keith Moore , Subject: RE: Node Requirements Issue 3 In-Reply-To: <5.1.0.14.2.20021027201851.025bf470@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 27 Oct 2002, Margaret Wasserman wrote: > Could you elaborate a bit more? > > Are there particular problems that would be caused by > limiting the use of site-local addresses to non-globally- > connected networks? I believe often an issue here is that OS/application vendors can just bind all the local services to nodes' site-local addresses, and make the security someone else's (ie router vendor, because site locals must not go out of the site) problem. Needless to say that sounds pretty much like "NAT protection" today.. Pekka > At 12:53 PM 10/24/02, Richard Draves wrote: > >This is craziness. We (I don't mean just MS) have shipping > >implementations that support site-locals. We have operational > >deployments using site-locals. We have applications that work just fine > >with site-locals. > > > >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 > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 27 23:43:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S7hE29006692; Sun, 27 Oct 2002 23:43:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9S7hExI006691; Sun, 27 Oct 2002 23:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9S7hB29006684 for ; Sun, 27 Oct 2002 23:43:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9S7hJbB016811 for ; Sun, 27 Oct 2002 23:43:19 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08893 for ; Mon, 28 Oct 2002 00:43:13 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA21686; Mon, 28 Oct 2002 09:43:01 +0200 Date: Mon, 28 Oct 2002 09:43:01 +0200 Message-Id: <200210280743.JAA21686@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: richdr@microsoft.com, rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20021027215436.03335b70@mail.windriver.com> (message from Margaret Wasserman on Sun, 27 Oct 2002 21:56:41 -0500) Subject: Re: Node Requirements Issue 3 References: <5.1.0.14.2.20021027215436.03335b70@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > When a multi-sited implementation gets site-local addresses from > the DNS (assuming that it runs two-faced DNS and returns site-locals), > how will the multi-sited host know which site the addresses are in? My guess, and tentative implementation is that the resolver library completes the scope id to the address using the interface from which the DNS reply came in. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 04:45:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCjS29007450; Mon, 28 Oct 2002 04:45:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SCjSQc007449; Mon, 28 Oct 2002 04:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCjO29007441; Mon, 28 Oct 2002 04:45:24 -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 g9SCjXbB020283; Mon, 28 Oct 2002 04:45:33 -0800 (PST) Received: from gateus.nmss.com (gateus.nmss.com [208.236.204.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA06730; Mon, 28 Oct 2002 05:45:27 -0700 (MST) Received: from [10.1.3.12] by gateus.nmss.com via smtpd (for patan.Sun.COM [192.18.98.43]) with SMTP; 28 Oct 2002 07:41:01 UT Subject: Re: Node Requirements Issue 7 To: Cc: ipng@sunroof.eng.sun.com, owner-ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 28 Oct 2002 06:45:03 -0600 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 10/28/2002 07:41:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with this. Adam Machalek To: Sent by: cc: 10/27/2002 06:19 AM Hi all, Issue 7 is: 7) Sub-IP layers (IP over Foo) - should all be included, or just one or two? Brian Haberman said: Given that new layer-2 technologies will appear and future docs may/will define how IPv6 runs over those layers, I would suggest using generic text that says that if a vendor wants to support IPv6 over a particular L2, then they must implement the IPv6-over-foo spec for that L2. Then I would give a few examples (IPv6-over-ethernet, etc.). I agree, what does the list think? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 04:49:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCnj29007467; Mon, 28 Oct 2002 04:49:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SCnjVw007466; Mon, 28 Oct 2002 04:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCnf29007459 for ; Mon, 28 Oct 2002 04:49: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 g9SCnoMq007894 for ; Mon, 28 Oct 2002 04:49:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19508 for ; Mon, 28 Oct 2002 04:49:45 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SCne017813; Mon, 28 Oct 2002 07:49:40 -0500 (EST) Message-Id: <200210281249.g9SCne017813@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements issue 8 In-reply-to: (Your message of "Mon, 28 Oct 2002 08:51:50 +0200.") Date: Mon, 28 Oct 2002 07:49:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 4) For IPv6 nodes, DNS MAY be included. IMHO this is the correct option. If apps require it then it will be included regardless of what this document says. And nothing stops apps from implementing DNS themselves (i.e. linking in an appropriate library which is available to the app developer whether or not it is available on the node). DNS is just an application protocol anyway. Also, I think the purpose of this document is not so much to state what functions are required of a node by its own applications, since these will presumably drive the function of the node anyway. I think it needs to state what node functions are required by other nodes, or by the network. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 04:53:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCrI29007513; Mon, 28 Oct 2002 04:53:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SCrIkG007512; Mon, 28 Oct 2002 04:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SCrE29007505 for ; Mon, 28 Oct 2002 04: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 g9SCrNbB021141 for ; Mon, 28 Oct 2002 04:53:23 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21060 for ; Mon, 28 Oct 2002 04:53:18 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SCpu017837; Mon, 28 Oct 2002 07:51:56 -0500 (EST) Message-Id: <200210281251.g9SCpu017837@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Margaret Wasserman , Richard Draves , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Mon, 28 Oct 2002 09:36:51 +0200.") Date: Mon, 28 Oct 2002 07:51:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe often an issue here is that OS/application vendors can just bind > all the local services to nodes' site-local addresses, and make the > security someone else's (ie router vendor, because site locals must not go > out of the site) problem. IMHO this is a really good reason for deprecating SLs entirely. if nothing else, we should make it very clear that it is not acceptable for developers/vendors to assume that the threats from the local network are less, or significantly different, than the threats presented by the global Internet. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 05:21:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDLg29007715; Mon, 28 Oct 2002 05:21:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SDLgMd007714; Mon, 28 Oct 2002 05:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDLd29007705; Mon, 28 Oct 2002 05:21:39 -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 g9SDLmbB024825; Mon, 28 Oct 2002 05:21:48 -0800 (PST) Received: from gateus.nmss.com (gateus.nmss.com [208.236.204.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA03549; Mon, 28 Oct 2002 05:21:42 -0800 (PST) Received: from [10.1.3.12] by gateus.nmss.com via smtpd (for nwkea-mail-2.sun.com [192.18.42.14]) with SMTP; 28 Oct 2002 08:17:16 UT Subject: Re: Node Requirements issue 8 To: Cc: ipng@sunroof.eng.sun.com, owner-ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 28 Oct 2002 07:21:37 -0600 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 10/28/2002 08:17:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For DNS, I'd like to see a MAY. Some systems simply have no need for DNS. Turning it into a mandatory requirement, or even a strong SHOULD is to much. This is a case where if you need it, put it in, if your system doesn't need it, don't put it in. As for DHCPv6, in order to have some consistancy with RFC2462 and that RFC's statements on Stateful Address config, this should probabally be a SHOULD here. On the otherhand, a MAY with descriptive language clearing up the ambiguity in RFC2462 would also be suffiicient. Adam Machalek To: Sent by: cc: 10/27/2002 06:23 AM Hi all, 8) Support for DNS (is it a MUST)? Support for DNS discovery / DHCP? The design team has waviered over DNS. Some say a strong SHOULD is enough, others say it is a MUST. What does this list feel? Should some level of DNS discovery / configuration be mandatory if DNS is used? I guess manual configuration would be a MUST in that case. The on-going DNS discovery issue still is yet to be completed, but could we mention something in the draft+ Also, what about DHCPv6? Is it mandatory, if so what are the madatory components, etc. Should it be mandatory for all types of devices? I think a SHOULD or MAY, with some detail may be sufficient. best regards, 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 05:37:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDbs29007822; Mon, 28 Oct 2002 05:37:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SDbsiv007821; Mon, 28 Oct 2002 05:37:54 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDbo29007812; Mon, 28 Oct 2002 05:37:50 -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 g9SDbxMq013832; Mon, 28 Oct 2002 05:37:59 -0800 (PST) Received: from gateus.nmss.com (gateus.nmss.com [208.236.204.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA00905; Mon, 28 Oct 2002 06:37:53 -0700 (MST) Received: from [10.1.3.12] by gateus.nmss.com via smtpd (for kathmandu.sun.com [192.18.98.36]) with SMTP; 28 Oct 2002 08:33:27 UT Subject: Re: Node Requirements Issue 9 To: Cc: ipng@sunroof.eng.sun.com, owner-ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 28 Oct 2002 07:37:47 -0600 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 10/28/2002 08:33:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I vote Strongly for a MAY. This is clearly a case where the Vendor/Developer in concert with the Customer/User should define what kind of transition stratagy is desirable for a particular implementation. At most, a statement that "A system should have some transition stratagy" would be acceptable. However, I would don't want to see any particular transition mechanisms specified a SHOULD or MUST. Adam Machalek To: Sent by: cc: 10/27/2002 06:25 AM Hi all, 9) Are Transition mechanisms mandatory; is support for IPv4 mandatory? I think that IPv4 is not mandatory, but a strong SHOULD. If IPv4 is supported, then some sort of transition mechanism is madatory - anyone have suggestions on what should be mandatory? Text suggestions are helpful. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 05:38:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDcG29007834; Mon, 28 Oct 2002 05:38:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SDcGlF007833; Mon, 28 Oct 2002 05:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDcB29007826 for ; Mon, 28 Oct 2002 05:38:11 -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 g9SDcKbB026928 for ; Mon, 28 Oct 2002 05:38:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13606 for ; Mon, 28 Oct 2002 06:38:14 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA10239; Mon, 28 Oct 2002 05:37:57 -0800 (PST) Message-Id: <5.1.0.14.2.20021028083649.03338d90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 08:38:02 -0500 To: Pekka Savola From: Margaret Wasserman Subject: RE: Node Requirements Issue 3 Cc: Richard Draves , Keith Moore , In-Reply-To: References: <5.1.0.14.2.20021027201851.025bf470@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I believe often an issue here is that OS/application vendors can just bind >all the local services to nodes' site-local addresses, and make the >security someone else's (ie router vendor, because site locals must not go >out of the site) problem. > >Needless to say that sounds pretty much like "NAT protection" today.. Right. With the added "feature" that site-local IPv6 traffic may transit IPv4 networks (via tunnels) that are not part of the local site... There are no security benefits to site-local addressing that can't be better realized by appropriate filtering rules in routers. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 05:49:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDnk29007969; Mon, 28 Oct 2002 05:49:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SDnkqf007968; Mon, 28 Oct 2002 05:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SDnh29007961 for ; Mon, 28 Oct 2002 05:49:43 -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 g9SDnqMq015369 for ; Mon, 28 Oct 2002 05:49:52 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18781 for ; Mon, 28 Oct 2002 06:49:46 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA14555; Mon, 28 Oct 2002 05:49:06 -0800 (PST) Message-Id: <5.1.0.14.2.20021028083809.033492a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 08:50:30 -0500 To: Markku Savela From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 Cc: richdr@microsoft.com, rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <200210280743.JAA21686@burp.tkv.asdf.org> References: <5.1.0.14.2.20021027215436.03335b70@mail.windriver.com> <5.1.0.14.2.20021027215436.03335b70@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:43 AM 10/28/02, Markku Savela wrote: > > When a multi-sited implementation gets site-local addresses from > > the DNS (assuming that it runs two-faced DNS and returns site-locals), > > how will the multi-sited host know which site the addresses are in? > >My guess, and tentative implementation is that the resolver library >completes the scope id to the address using the interface from which >the DNS reply came in. I keep winding-up back here, myself, but it isn't really a satisfactory answer for several reasons: (1) A multi-sited node might receive different sets of addresses in response to the same query, based on which site's DNS server was tried first. There is no provision to try another DNS server if the first one succeeds, so there is no way to be sure you've gotten all of the available addresses to reach a node. (2) This solution presumes some relationship between the routing hierarchy and the organization of DNS servers. For example, it assumes that I will use the DNS server that is configured with two-faced DNS for my site. (3) The two-faced DNS solution requires that we store routing information in a DNS configuration file. This creates another way for the network to break when routing information changes. (4) If the DNS requests are done via global addresses, I am not sure that it is safe to assume that the results will always come back through the correct interface. What if there were a partition in Site1, but parts of Site1 could still reach other parts of Site1 using global addresses, by sending across the global Internet. Is that possible? Anyway, we'd certainly have to document the "two-faced" DNS concept and describe this solution in more detail before I'd feel comfortable counting on it to work. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 06:11:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEB529008066; Mon, 28 Oct 2002 06:11:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SEB5RY008065; Mon, 28 Oct 2002 06:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEB129008058 for ; Mon, 28 Oct 2002 06:11:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SEBBMq017973 for ; Mon, 28 Oct 2002 06:11:11 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27678 for ; Mon, 28 Oct 2002 06:11:05 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9SEAQaZ187432; Mon, 28 Oct 2002 09:10:27 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9SEAOam049870; Mon, 28 Oct 2002 09:10:24 -0500 In-Reply-To: <200210280743.JAA21686@burp.tkv.asdf.org> To: Markku Savela Cc: ipng@sunroof.eng.sun.com, mrw@windriver.com, richdr@microsoft.com Subject: Re: Node Requirements Issue 3 MIME-Version: 1.0 Sensitivity: 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 10/28/2002 09:10:17 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 10/28/2002 09:10:17 AM, Serialize complete at 10/28/2002 09:10:17 AM, S/MIME Sign failed at 10/28/2002 09:10:17 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/28/2002 08:10:26, Serialize complete at 10/28/2002 08:10:26 Message-ID: Date: Mon, 28 Oct 2002 10:10:25 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > When a multi-sited implementation gets site-local addresses from > > the DNS (assuming that it runs two-faced DNS and returns site-locals), > > how will the multi-sited host know which site the addresses are in? > > My guess, and tentative implementation is that the resolver library > completes the scope id to the address using the interface from which > the DNS reply came in. You may also need to send the DNS query into each site-local scope zone in order to obtain all necessary results, or even to obtain any results, if a given host name only resolves to site-local addresses in one of the site-local scope zones. If the DNS name server is on a muti-sited host (which I suppose makes sense if it is performing name-to-address resolution for hosts which are muti-sited), then it needs to be configured to return different site-local addresses for each given site to which it is connected. Since Stateless Address Autoconfiguration or (eventually) DHCPv6 may be used to configure addresses, the DNS name server also needs to understand the site-local scope zone over which a DNS registration is made, placing "global" addresses into the "global" pool and "site-local" addresses associated with the site-local scope zone over which the registration is received. Likewise, the host performing the registration needs to restrict the site-local addresses which are registered to the site-local scope zone in which they are valid. There are probably other requirements for this to work as well. The only point I'm trying to make is it isn't just as simple as connecting to multiple sites and having this work properly without additional standards being defined. 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 Mon Oct 28 06:43:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEhw29008250; Mon, 28 Oct 2002 06:43:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SEhwT3008249; Mon, 28 Oct 2002 06:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEhr29008241; Mon, 28 Oct 2002 06:43:53 -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 g9SEi2bB006019; Mon, 28 Oct 2002 06:44:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14497; Mon, 28 Oct 2002 06:43:57 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SEhT018932; Mon, 28 Oct 2002 09:43:29 -0500 (EST) Message-Id: <200210281443.g9SEhT018932@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Adam Machalek" cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com, owner-ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 9 In-reply-to: (Your message of "Mon, 28 Oct 2002 07:37:47 CST.") Date: Mon, 28 Oct 2002 09:43:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I vote Strongly for a MAY. This is clearly a case where the > Vendor/Developer in concert with the Customer/User should define what kind > of transition stratagy is desirable for a particular implementation. At > most, a statement that "A system should have some transition stratagy" > would be acceptable. However, I would don't want to see any particular > transition mechanisms specified a SHOULD or MUST. I'm fairly convinced that (for nodes that support v4 in addition to v6) there needs to be a "must implement" transition strategy, otherwise we will get not only devices but applications that can only work with a particular network configuration (since the apps will depend on the artifacts or lack thereof of a particular transition strategy). Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 06:45:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEjP29008279; Mon, 28 Oct 2002 06:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SEjPck008278; Mon, 28 Oct 2002 06:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SEjK29008264 for ; Mon, 28 Oct 2002 06:45:20 -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 g9SEjTMq027031 for ; Mon, 28 Oct 2002 06:45:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06913 for ; Mon, 28 Oct 2002 07:45:24 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SEjE018961; Mon, 28 Oct 2002 09:45:15 -0500 (EST) Message-Id: <200210281445.g9SEjE018961@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Markku Savela , richdr@microsoft.com, rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Mon, 28 Oct 2002 08:50:30 EST.") <5.1.0.14.2.20021028083809.033492a0@mail.windriver.com> Date: Mon, 28 Oct 2002 09:45:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk anything that encourages multi-faced DNS is a bad idea. Keith > At 02:43 AM 10/28/02, Markku Savela wrote: > > > > When a multi-sited implementation gets site-local addresses from > > > the DNS (assuming that it runs two-faced DNS and returns site-locals), > > > how will the multi-sited host know which site the addresses are in? > > > >My guess, and tentative implementation is that the resolver library > >completes the scope id to the address using the interface from which > >the DNS reply came in. > > I keep winding-up back here, myself, but it isn't really a satisfactory > answer for several reasons: > > (1) A multi-sited node might receive different sets of > addresses in response to the same query, based on > which site's DNS server was tried first. There is > no provision to try another DNS server if the first > one succeeds, so there is no way to be sure you've > gotten all of the available addresses to reach a > node. > > (2) This solution presumes some relationship between the > routing hierarchy and the organization of DNS servers. > For example, it assumes that I will use the DNS > server that is configured with two-faced DNS for my > site. > > (3) The two-faced DNS solution requires that we store routing > information in a DNS configuration file. This creates > another way for the network to break when routing > information changes. > > (4) If the DNS requests are done via global addresses, I am > not sure that it is safe to assume that the results > will always come back through the correct interface. > What if there were a partition in Site1, but parts of > Site1 could still reach other parts of Site1 using > global addresses, by sending across the global > Internet. Is that possible? > > Anyway, we'd certainly have to document the "two-faced" DNS concept > and describe this solution in more detail before I'd feel comfortable > counting on it to work. > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 07:32:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFW429008820; Mon, 28 Oct 2002 07:32:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SFW3Tq008819; Mon, 28 Oct 2002 07:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFVx29008812 for ; Mon, 28 Oct 2002 07:31:59 -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 g9SFW9bB014568 for ; Mon, 28 Oct 2002 07:32:09 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13630 for ; Mon, 28 Oct 2002 07:32:03 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SFVw019147; Mon, 28 Oct 2002 10:31:58 -0500 (EST) Message-Id: <200210281531.g9SFVw019147@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Roy Brabson cc: Markku Savela , ipng@sunroof.eng.sun.com, mrw@windriver.com, richdr@microsoft.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Mon, 28 Oct 2002 10:10:25 -0400.") Date: Mon, 28 Oct 2002 10:31:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the DNS name server is on a muti-sited host > (which I suppose makes sense if it is performing name-to-address > resolution for hosts which are muti-sited), then it needs to be configured > to return different site-local addresses for each given site to which it > is connected. Distributed applications depend on consistent results from DNS, regardless of where the query came from. > Since Stateless Address Autoconfiguration or (eventually) DHCPv6 may be > used to configure addresses, the DNS name server also needs to understand > the site-local scope zone over which a DNS registration is made, placing > "global" addresses into the "global" pool and "site-local" addresses > associated with the site-local scope zone over which the registration is > received. As if such scope were visible to the DNS server (it isn't), or the DNS server could depend on results only being used in the scope for which they were intended (it can't). > Likewise, the host performing the registration needs to > restrict the site-local addresses which are registered to the site-local > scope zone in which they are valid. except that there's no way for the host to know where those addresses are valid. > There are probably other requirements for this to work as well. The only > point I'm trying to make is it isn't just as simple as connecting to > multiple sites and having this work properly without additional standards > being defined. indeed. and what compelling purpose does all of this complexity serve? none that I can see. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 07:38:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFce29008864; Mon, 28 Oct 2002 07:38:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SFceBp008863; Mon, 28 Oct 2002 07:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFcb29008856 for ; Mon, 28 Oct 2002 07:38:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SFckbB015803 for ; Mon, 28 Oct 2002 07:38:46 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16082 for ; Mon, 28 Oct 2002 07:38:41 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA11254; Mon, 28 Oct 2002 07:37:57 -0800 (PST) Message-Id: <5.1.0.14.2.20021028103808.0332b740@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 10:39:28 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 Cc: Roy Brabson , Markku Savela , ipng@sunroof.eng.sun.com, richdr@microsoft.com In-Reply-To: <200210281531.g9SFVw019147@astro.cs.utk.edu> References: <(Your message of "Mon, 28 Oct 2002 10:10:25 -0400.") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >and what compelling purpose does all of this complexity serve? >none that I can see. I think that this is a key question. Could folks who support the use of site-local addresses on globally-connected networks explain what benefits they offer that out-weigh the considerable costs? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 07:41:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFfR29008899; Mon, 28 Oct 2002 07:41:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SFfRcK008898; Mon, 28 Oct 2002 07:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SFfO29008891 for ; Mon, 28 Oct 2002 07:41: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 g9SFfYMq007117 for ; Mon, 28 Oct 2002 07:41:34 -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 IAA05608 for ; Mon, 28 Oct 2002 08:41:28 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA13742 for ; Mon, 28 Oct 2002 07:41:23 -0800 (PST) Message-Id: <5.1.0.14.2.20021028104021.03333b30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 10:42:52 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Limiting the Use of Site-Local (Re: Node Requirements Issue 3) In-Reply-To: <200210281531.g9SFVw019147@astro.cs.utk.edu> References: <(Your message of "Mon, 28 Oct 2002 10:10:25 -0400.") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It has been pointed out to me that having an extensive discussion of whether or not the IPv6 WG should limit the use of site-local addresses to non-globally-connected networks in a lengthy thread called "Node Requirements Issue 3" may be flying below the radar for many IPv6 list members. So, let's try to move the discussion to this new subject. Folks who want to know what has already been said should read the aforementioned thread. Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:11:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGBf29009147; Mon, 28 Oct 2002 08:11:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGBeIC009146; Mon, 28 Oct 2002 08:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGBb29009139 for ; Mon, 28 Oct 2002 08:11:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SGBlMq013446 for ; Mon, 28 Oct 2002 08:11:47 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05811 for ; Mon, 28 Oct 2002 08:11:41 -0800 (PST) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9SGBaH18327; Mon, 28 Oct 2002 11:11:36 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9SGBZZ61337; Mon, 28 Oct 2002 11:11:35 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id LAA02431; Mon, 28 Oct 2002 11:11:32 -0500 (EST) Subject: Re: Limiting the Use of Site-Local From: Steven Blake To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20021028104021.03333b30@mail.windriver.com> References: <(Your message of "Mon, 28 Oct 2002 10:10:25 -0400.") <5.1.0.14.2.20021028104021.03333b30@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Oct 2002 11:11:31 -0500 Message-Id: <1035821492.35924.15.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2002-10-28 at 10:39, Margaret Wasserman wrote: > >and what compelling purpose does all of this complexity serve? > >none that I can see. > > I think that this is a key question. > > Could folks who support the use of site-local addresses on > globally-connected networks explain what benefits they > offer that out-weigh the considerable costs? Are you suggesting that someone should actually write router code to prevent this (i.e., treat site-locals as anything other than regular unicast addresses)? It would be better to produce a "Use of Non-Globally Reachable Unicast Addresses" BCP rather than put meaningless restrictions on address use in the specs. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 08:33:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGXL29009654; Mon, 28 Oct 2002 08:33:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGXKAR009653; Mon, 28 Oct 2002 08:33:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGXH29009646 for ; Mon, 28 Oct 2002 08:33:17 -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 g9SGXQMq018712 for ; Mon, 28 Oct 2002 08:33:27 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20021 for ; Mon, 28 Oct 2002 08:33:21 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SGXIQ1016921; Mon, 28 Oct 2002 17:33:18 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 17:33:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C00@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Steven Blake'" , Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 17:33:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >and what compelling purpose does all of this complexity serve? > > >none that I can see. > > > > I think that this is a key question. > > > > Could folks who support the use of site-local addresses on > > globally-connected networks explain what benefits they > > offer that out-weigh the considerable costs? > > Are you suggesting that someone should actually write router code to > prevent this (i.e., treat site-locals as anything other than regular > unicast addresses)? > > It would be better to produce a "Use of Non-Globally > Reachable Unicast > Addresses" BCP rather than put meaningless restrictions on > address use > in the specs. => This makes a lot more sense IMHO. How can we write "MUST NOT use site-local when global addresses are available" in a spec? I mean how can we enforce that? If we can't enforce a "MUST" or "MUST NOT" then it shouldn't be in the spec in the first place. Hesham > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure +1 919-472-9913 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 28 08:38:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGcM29009749; Mon, 28 Oct 2002 08:38:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGcMZg009748; Mon, 28 Oct 2002 08:38:22 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGcI29009741 for ; Mon, 28 Oct 2002 08:38:19 -0800 (PST) Received: from localhost (vpn-129-156-97-15.EMEA.Sun.COM [129.156.97.15]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9SGcOL06645; Mon, 28 Oct 2002 17:38:24 +0100 (MET) Date: Mon, 28 Oct 2002 17:35:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt To: Richard Draves Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is > that site-locals are put in the DNS and it specifies a way for a node to > filter out the site-locals when they shouldn't be used). It can be > extended to the situation of an application on one node sending > addresses to an application on another node. The simple idea is to just > send all your global & site-local addresses, then the receiving node > does the same filtering specified by draft-ietf-ipngwg-site-prefixes-05, > and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order > to try the addresses. That long expired draft explicitly stated the assumption that all IPv6 nodes had to be modified to filter out site-local addresses from RRsets that contain both globals and site-locals. That was not an outlandish idea when the draft was first written, but today there is enough implementations of IPv6 with deployment starting to happen that that assumption would be a non-starter. One could of course suggest a mechanism where the DNS clients explicitly need to request something different to let the server know that they are capable of filtering site-locals that are in a different site. But personally I feel that adding such things to the DNS (whether it be a new address RRtype or something else) adds far to much complexity and has performance implications, that it makes no sense given the relatively limited benefit of using site-local addresses when global addresses are available. So the approach of putting site-local addresses in the global DNS doesn't seem worth-while. My 2 cents, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:48:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGmF29009996; Mon, 28 Oct 2002 08:48:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGmEAe009995; Mon, 28 Oct 2002 08:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGmB29009988 for ; Mon, 28 Oct 2002 08:48:11 -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 g9SGmLMq022296 for ; Mon, 28 Oct 2002 08:48:21 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00769 for ; Mon, 28 Oct 2002 09:48:15 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA28068; Mon, 28 Oct 2002 08:47:58 -0800 (PST) Message-Id: <5.1.0.14.2.20021028114203.07a6ac00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 11:44:50 -0500 To: Steven Blake From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1035821492.35924.15.camel@newcastle.torrentnet.com> References: <5.1.0.14.2.20021028104021.03333b30@mail.windriver.com> <(Your message of "Mon, 28 Oct 2002 10:10:25 -0400.") <5.1.0.14.2.20021028104021.03333b30@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Are you suggesting that someone should actually write router code to >prevent this (i.e., treat site-locals as anything other than regular >unicast addresses)? No. In fact, I am suggesting that all routers and hosts treat site-local unicast addresses exactly like global unicast addresses, and that we administratively restrict the use of site-local unicast addresses to non-globally-connected networks. If site-locals are used on globally-connected networks, it is necessary for them to be treated specially by the IP stack (address selection rules), DNS resolvers, applications, routing protocols and management software. And, I am suggesting that we do not want to define this usage. >It would be better to produce a "Use of Non-Globally Reachable Unicast >Addresses" BCP rather than put meaningless restrictions on address use >in the specs. What would you suggest as the contents of that BCP? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:48:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGmL29010010; Mon, 28 Oct 2002 08:48:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGmLTF010009; Mon, 28 Oct 2002 08:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGmH29010000 for ; Mon, 28 Oct 2002 08:48:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SGmQbB000345 for ; Mon, 28 Oct 2002 08:48:26 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28240 for ; Mon, 28 Oct 2002 09:48:20 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA28230; Mon, 28 Oct 2002 08:48:05 -0800 (PST) Message-Id: <5.1.0.14.2.20021028114509.07a70b50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 11:49:31 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'Steven Blake'" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C00@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >=> This makes a lot more sense IMHO. How can we write >"MUST NOT use site-local when global addresses are available" >in a spec? I mean how can we enforce that? If we can't enforce >a "MUST" or "MUST NOT" then it shouldn't be in the spec >in the first place. I disagree. The scoped addressing architecture will define how scoped addresses are used on the network. It already has lots of things in it that can't be "enforced" programmatically on a single node, such as: - scope boundaries are in nodes, not on links - scopes are contiguous and convex - smaller scopes are completely contained within larger scopes All of these things require that an administrator configure a network in a way that meets these guidelines. Similarly, we could say that site-local addresses should not be assigned on globally-connected networks. Besides, it would be possible (although perhaps not adviseable) to enforce this restriction. Nodes could immediately deprecate site-local addresses whenever a global address is configured. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:52:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGqP29010084; Mon, 28 Oct 2002 08:52:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGqPdk010083; Mon, 28 Oct 2002 08:52:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGqL29010076 for ; Mon, 28 Oct 2002 08:52:21 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20404; Mon, 28 Oct 2002 11:52:30 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9SGqUrL008426; Mon, 28 Oct 2002 11:52:30 -0500 (EST) Message-Id: <200210281652.g9SGqUrL008426@thunk.east.sun.com> From: Bill Sommerfeld To: "Hesham Soliman (EAB)" cc: "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Mon, 28 Oct 2002 17:33:15 +0100." <4DA6EA82906FD511BE2F00508BCF0538044F0C00@Esealnt861.al.sw.ericsson.se> Reply-to: sommerfeld@east.sun.com Date: Mon, 28 Oct 2002 11:52:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If we can't enforce a "MUST" or "MUST NOT" then it shouldn't be in > the spec in the first place. Does not follow. The IETF has no enforcement authority. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 08:53:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGrY29010118; Mon, 28 Oct 2002 08:53:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGrYgJ010117; Mon, 28 Oct 2002 08:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGrU29010107 for ; Mon, 28 Oct 2002 08:53:30 -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 g9SGrdbB001628 for ; Mon, 28 Oct 2002 08:53:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22739 for ; Mon, 28 Oct 2002 09:53:33 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SGrRKV012966; Mon, 28 Oct 2002 17:53:27 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 17:53:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C01@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" Cc: "'Steven Blake'" , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 17:53:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >=> This makes a lot more sense IMHO. How can we write > >"MUST NOT use site-local when global addresses are available" > >in a spec? I mean how can we enforce that? If we can't enforce > >a "MUST" or "MUST NOT" then it shouldn't be in the spec > >in the first place. > > I disagree. The scoped addressing architecture will define how > scoped addresses are used on the network. It already has lots > of things in it that can't be "enforced" programmatically on a > single node, such as: > > - scope boundaries are in nodes, not on links > - scopes are contiguous and convex > - smaller scopes are completely contained within > larger scopes > > All of these things require that an administrator configure a > network in a way that meets these guidelines. => Because if he/she doesn't do that, communication will fail in many cases. But how can one force administrators who (for some reason we don't know now) decide to use both global and site-local prefixes in a site and defined SBRs to support this? That would break a MUST NOT in the spec, but things will still work. > > Similarly, we could say that site-local addresses should not be > assigned on globally-connected networks. > > Besides, it would be possible (although perhaps not adviseable) > to enforce this restriction. Nodes could immediately deprecate > site-local addresses whenever a global address is configured. => Just so they feel that they followed our standards? I don't think so. A much better approach IMHO would be to highlight the problems and discourage people from using site-local addresses for globally connected sites _because_ of the highlighted problems. After that you can hope that people will follow. That's all we can do. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:54:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGs429010156; Mon, 28 Oct 2002 08:54:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGs4CK010155; Mon, 28 Oct 2002 08:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGrw29010141 for ; Mon, 28 Oct 2002 08:53:58 -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 g9SGs8Mq023592 for ; Mon, 28 Oct 2002 08:54:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23073 for ; Mon, 28 Oct 2002 09:54:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SGrt019805; Mon, 28 Oct 2002 11:53:56 -0500 (EST) Message-Id: <200210281653.g9SGrt019805@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steven Blake cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "28 Oct 2002 11:11:31 EST.") <1035821492.35924.15.camel@newcastle.torrentnet.com> Date: Mon, 28 Oct 2002 11:53:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are you suggesting that someone should actually write router code to > prevent this (i.e., treat site-locals as anything other than regular > unicast addresses)? > > It would be better to produce a "Use of Non-Globally Reachable Unicast > Addresses" BCP rather than put meaningless restrictions on address use > in the specs. since when is a restriction 'meaningless' just because it doesn't affect routers? network designers, network maintainers, and application designers all need to realize that use of non-globals is in general a bad idea. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 08:56:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGub29010221; Mon, 28 Oct 2002 08:56:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGubr7010220; Mon, 28 Oct 2002 08:56:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGuX29010213 for ; Mon, 28 Oct 2002 08:56: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 g9SGuhMq024204 for ; Mon, 28 Oct 2002 08:56:43 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03908 for ; Mon, 28 Oct 2002 09:56:37 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SGuZKV013451; Mon, 28 Oct 2002 17:56:35 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 17:56:35 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C02@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'sommerfeld@east.sun.com'" Cc: "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 17:56:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If we can't enforce a "MUST" or "MUST NOT" then it shouldn't be in > > the spec in the first place. > > Does not follow. The IETF has no enforcement authority. => I certainly didn't mean to suggest that the IETF has an enforcement authority. I meant that this words are used in cases where: if not followed, the protocol will break. Therefore people generally follow them. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 08:57:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGva29010252; Mon, 28 Oct 2002 08:57:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SGvar4010250; Mon, 28 Oct 2002 08:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SGvV29010240 for ; Mon, 28 Oct 2002 08:57:31 -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 g9SGvfbB002531 for ; Mon, 28 Oct 2002 08:57:41 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05479 for ; Mon, 28 Oct 2002 08:57:35 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SGvU019820; Mon, 28 Oct 2002 11:57:30 -0500 (EST) Message-Id: <200210281657.g9SGvU019820@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 17:33:15 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C00@Esealnt861.al.sw.ericsson.se> Date: Mon, 28 Oct 2002 11:57:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This makes a lot more sense IMHO. How can we write > "MUST NOT use site-local when global addresses are available" > in a spec? I mean how can we enforce that? If we can't enforce > a "MUST" or "MUST NOT" then it shouldn't be in the spec > in the first place. how can IETF enforce anything it puts in a spec? by that logic we should get rid of all IETF standards, because IETF has no means of enforcing them. surely it's reasonable for IETF standards to establish constraints on the use of IETF standards. if you violate those constraints you can no longer expect to interoperate, and any interoperability failures you cause are your own fault. that's about all it's ever meant to violate an IETF standard, I don't see why this case should be any different. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 09:02:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SH2l29010411; Mon, 28 Oct 2002 09:02:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SH2lYK010410; Mon, 28 Oct 2002 09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SH2i29010402 for ; Mon, 28 Oct 2002 09:02:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SH2rMq026047 for ; Mon, 28 Oct 2002 09:02:53 -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 KAA28997 for ; Mon, 28 Oct 2002 10:02:47 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA08168; Mon, 28 Oct 2002 09:02:34 -0800 (PST) Message-Id: <5.1.0.14.2.20021028120036.07a714f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 12:04:02 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'Steven Blake'" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C01@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >=> Just so they feel that they followed our standards? >I don't think so. A much better approach IMHO would be >to highlight the problems and discourage people from >using site-local addresses for globally connected sites >_because_ of the highlighted problems. After that you >can hope that people will follow. That's all we can do. And, in this scenario, do we also document all of the things that are needed to make things sort-of work when administrators ignore our advice -- "two-faced" DNS, a complex nest of address selection rules, routing protocol rules for SBRs, etc? And, do we require (in node requirements) that people implement all of this cruft? If so, how are implementors supposed to distinguish between the things that they really need to implement (to make the usual case work), and the stuff that they only need to implement to support the not-recommended case? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:08:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SH8B29010548; Mon, 28 Oct 2002 09:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SH8BW9010547; Mon, 28 Oct 2002 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SH8729010538 for ; Mon, 28 Oct 2002 09:08:07 -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 g9SH8GbB005692 for ; Mon, 28 Oct 2002 09:08:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12484 for ; Mon, 28 Oct 2002 10:08:11 -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 JAA17330; Mon, 28 Oct 2002 09:08:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9SH8A630724; Mon, 28 Oct 2002 09:08:10 -0800 X-mProtect: <200210281708> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqi6bm5; Mon, 28 Oct 2002 09:08:08 PST Message-ID: <3DBD6EF9.472EE12C@iprg.nokia.com> Date: Mon, 28 Oct 2002 09:08:09 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <4DA6EA82906FD511BE2F00508BCF0538044F0C01@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Hesham, "Hesham Soliman (EAB)" wrote: > .... A much better approach IMHO would be > to highlight the problems and discourage people from > using site-local addresses for globally connected sites > _because_ of the highlighted problems. Doesn't this boil down to saying "SHOULD NOT" instead of "MUST NOT"? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:12:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHCK29010689; Mon, 28 Oct 2002 09:12:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHCKRi010688; Mon, 28 Oct 2002 09:12:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHCH29010678 for ; Mon, 28 Oct 2002 09:12:17 -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 g9SHCQMq028614 for ; Mon, 28 Oct 2002 09:12:26 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15761 for ; Mon, 28 Oct 2002 10:12:20 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SHCIKV016263; Mon, 28 Oct 2002 18:12:18 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 18:12:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C04@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Charles E. Perkins'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 18:12:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "Hesham Soliman (EAB)" wrote: > > > .... A much better approach IMHO would be > > to highlight the problems and discourage people from > > using site-local addresses for globally connected sites > > _because_ of the highlighted problems. > > Doesn't this boil down to saying "SHOULD NOT" instead > of "MUST NOT"? => Possibly. But my comment was that we explain the reasons in detail. That's why Steve's suggestion about a BCP made sense to me. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:14:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHE829010780; Mon, 28 Oct 2002 09:14:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHE8fI010779; Mon, 28 Oct 2002 09:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHDn29010761 for ; Mon, 28 Oct 2002 09:13: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 g9SHDwbB007170 for ; Mon, 28 Oct 2002 09:13:59 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06289 for ; Mon, 28 Oct 2002 10:13:53 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E32FE2E75; Mon, 28 Oct 2002 12:13:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Oct 2002 12:13: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: Node Requirements Issue 3 Date: Mon, 28 Oct 2002 12:13:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE973F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ+gWPjasKMBLXrSc68qJvrZycVPwAI9cBw From: "Bound, Jim" To: "Keith Moore" , "Pekka Savola" Cc: "Margaret Wasserman" , "Richard Draves" , X-OriginalArrivalTime: 28 Oct 2002 17:13:52.0351 (UTC) FILETIME=[637B16F0:01C27EA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SHDo29010764 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Richard has stated he has implemented this and has customers. Lets here him out. I don't like them either but that means something to me anyway. Richard ??? /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, October 28, 2002 7:52 AM > To: Pekka Savola > Cc: Margaret Wasserman; Richard Draves; Keith Moore; > ipng@sunroof.eng.sun.com > Subject: Re: Node Requirements Issue 3 > > > > I believe often an issue here is that OS/application > vendors can just > > bind all the local services to nodes' site-local addresses, > and make > > the security someone else's (ie router vendor, because site locals > > must not go out of the site) problem. > > IMHO this is a really good reason for deprecating SLs entirely. > > if nothing else, we should make it very clear that it is not > acceptable > for developers/vendors to assume that the threats from the > local network > are less, or significantly different, than the threats presented by > the global Internet. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:19:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHJv29011054; Mon, 28 Oct 2002 09:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHJvZZ011053; Mon, 28 Oct 2002 09:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHJs29011046 for ; Mon, 28 Oct 2002 09:19:54 -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 g9SHK3Mq001027 for ; Mon, 28 Oct 2002 09:20:03 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29384 for ; Mon, 28 Oct 2002 10:19:57 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SHJtKV017545; Mon, 28 Oct 2002 18:19:55 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 18:19:55 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C05@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "'Steven Blake'" , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 18:19:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >=> Just so they feel that they followed our standards? > >I don't think so. A much better approach IMHO would be > >to highlight the problems and discourage people from > >using site-local addresses for globally connected sites > >_because_ of the highlighted problems. After that you > >can hope that people will follow. That's all we can do. > > And, in this scenario, do we also document all of the things that > are needed to make things sort-of work when administrators ignore > our advice -- "two-faced" DNS, a complex nest of address selection > rules, routing protocol rules for SBRs, etc? => Well, if one says "Administrators MUST NOT do X" there is no need to show them how to go around that MUST NOT ;) But you could use the reasons you mention above to justify the MUST NOT. > > And, do we require (in node requirements) that people implement > all of this cruft? => Why would we do that if the recommendation is: "MUST NOT use SL addresses for globally connected networks" ?? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:25:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHPM29011198; Mon, 28 Oct 2002 09:25:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHPMDb011197; Mon, 28 Oct 2002 09:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHPJ29011190 for ; Mon, 28 Oct 2002 09:25:19 -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 g9SHPSMq002693 for ; Mon, 28 Oct 2002 09:25:29 -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 JAA23560 for ; Mon, 28 Oct 2002 09:25:23 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 09:25:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C7@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+owg3jEomRtNZQDST/PNQLW03QAAAprtQ From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SHPJ29011191 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Besides, it would be possible (although perhaps not > adviseable) to enforce this restriction. Nodes could > immediately deprecate site-local addresses whenever a > global address is configured. I think this is a terrible idea. I can envision many situations where a host would need both a site-local and a global address. > In fact, I am suggesting that all routers and hosts treat > site-local unicast addresses exactly like global unicast > addresses, and that we administratively restrict the use > of site-local unicast addresses to non-globally-connected > networks. I am comfortable with this. It's roughly what we do with RFC1918 addresses today, and it has worked fine for many people. Link-locals are not routable, but site-locals are within the site, and since hopefully nobody will invent IPv6 NAT, filtering site-local addresses at the edge of the site seems the appropriate solution to me. My $0.02 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 Oct 28 09:26:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHQk29011239; Mon, 28 Oct 2002 09:26:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHQkXH011238; Mon, 28 Oct 2002 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHQg29011231 for ; Mon, 28 Oct 2002 09:26:42 -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 g9SHQpbB011184 for ; Mon, 28 Oct 2002 09:26:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15021 for ; Mon, 28 Oct 2002 10:26:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SHP7019914; Mon, 28 Oct 2002 12:25:10 -0500 (EST) Message-Id: <200210281725.g9SHP7019914@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , "Pekka Savola" , "Margaret Wasserman" , "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Mon, 28 Oct 2002 12:13:51 EST.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE973F@tayexc13.americas.cpqcorp.net> Date: Mon, 28 Oct 2002 12:25:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Richard has stated he has implemented this and has customers. Lets here > him out. by all means, if there are good reasons to impose this considerable burden on applications, let's hear them. of course, just because there are implementations of SL and that customers have bought those implementations doesn't mean that widespread use of SLs is something that IETF should endorse. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:32:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHWl29011356; Mon, 28 Oct 2002 09:32:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHWkv9011355; Mon, 28 Oct 2002 09:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHWh29011348 for ; Mon, 28 Oct 2002 09:32: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 g9SHWqbB013269 for ; Mon, 28 Oct 2002 09:32:53 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29944 for ; Mon, 28 Oct 2002 10:32:47 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA05617; Mon, 28 Oct 2002 09:32:32 -0800 (PST) Message-Id: <5.1.0.14.2.20021028123201.07a75a70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 12:32:57 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Hesham Soliman (EAB)" , "'Steven Blake'" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C05@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Okay, good. It looks like we are, somewhat, on the same page. Let's try to figure out what restrictions we think would make sense, then we can figure out whether it makes the most sense to document them in a standards track document or a BCP, okay? Margaret At 12:19 PM 10/28/02, Hesham Soliman (EAB) wrote: > > >=> Just so they feel that they followed our standards? > > >I don't think so. A much better approach IMHO would be > > >to highlight the problems and discourage people from > > >using site-local addresses for globally connected sites > > >_because_ of the highlighted problems. After that you > > >can hope that people will follow. That's all we can do. > > > > And, in this scenario, do we also document all of the things that > > are needed to make things sort-of work when administrators ignore > > our advice -- "two-faced" DNS, a complex nest of address selection > > rules, routing protocol rules for SBRs, etc? > >=> Well, if one says "Administrators MUST NOT do X" >there is no need to show them how to go around that MUST NOT ;) >But you could use the reasons you mention above to justify >the MUST NOT. > > > > > And, do we require (in node requirements) that people implement > > all of this cruft? > >=> Why would we do that if the recommendation is: "MUST NOT use >SL addresses for globally connected networks" ?? > >Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:38:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHcB29011446; Mon, 28 Oct 2002 09:38:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHcBPP011445; Mon, 28 Oct 2002 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHc829011438 for ; Mon, 28 Oct 2002 09:38: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 g9SHcHbB014980 for ; Mon, 28 Oct 2002 09:38:17 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03559 for ; Mon, 28 Oct 2002 09:38:12 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D89662C37; Mon, 28 Oct 2002 12:38: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); Mon, 28 Oct 2002 12:38:12 -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: Node Requirements Issue 3 Date: Mon, 28 Oct 2002 12:38:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE974A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcJ+pv38lbviFeKJTreImn8tMxQVcQAAZ/3g From: "Bound, Jim" To: "Keith Moore" Cc: "Pekka Savola" , "Margaret Wasserman" , "Richard Draves" , X-OriginalArrivalTime: 28 Oct 2002 17:38:12.0013 (UTC) FILETIME=[C981D5D0:01C27EA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SHc829011439 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree Keith but just want a logic check for my own sanity. I am with you on all mail. Just want to check. I think they are far more trouble than any benefit I can see for users and I fear greatly it causing a NAT problem which is just not good. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, October 28, 2002 12:25 PM > To: Bound, Jim > Cc: Keith Moore; Pekka Savola; Margaret Wasserman; Richard > Draves; ipng@sunroof.eng.sun.com > Subject: Re: Node Requirements Issue 3 > > > > Richard has stated he has implemented this and has customers. Lets > > here him out. > > by all means, if there are good reasons to impose this > considerable burden on applications, let's hear them. > > of course, just because there are implementations of SL and > that customers > have bought those implementations doesn't mean that > widespread use of SLs > is something that IETF should endorse. > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 09:42:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHgC29011508; Mon, 28 Oct 2002 09:42:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHgBXk011507; Mon, 28 Oct 2002 09:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHg829011500 for ; Mon, 28 Oct 2002 09:42:08 -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 g9SHgIMq008102 for ; Mon, 28 Oct 2002 09:42:18 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06933 for ; Mon, 28 Oct 2002 10:42:12 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E6F3E2CA3; Mon, 28 Oct 2002 12:42: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); Mon, 28 Oct 2002 12:42:11 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 12:42:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE974B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+owg3jEomRtNZQDST/PNQLW03QAAAprtQAADK6sA= From: "Bound, Jim" To: "Michel Py" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 28 Oct 2002 17:42:11.0434 (UTC) FILETIME=[583694A0:01C27EA9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SHg829011501 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael, Comments below. /jim [Have you ever seen the rain coming down on a sunny day] > > Margaret, > > > Besides, it would be possible (although perhaps not > > adviseable) to enforce this restriction. Nodes could immediately > > deprecate site-local addresses whenever a global address is > > configured. > > I think this is a terrible idea. I can envision many > situations where a host would need both a site-local and a > global address. I think this is a wonderful idea and would like to see it applied to src address selection as MUST. > > > > In fact, I am suggesting that all routers and hosts treat > site-local > > unicast addresses exactly like global unicast addresses, > and that we > > administratively restrict the use of site-local unicast > addresses to > > non-globally-connected networks. > > I am comfortable with this. It's roughly what we do with > RFC1918 addresses today, and it has worked fine for many > people. Link-locals are not routable, but site-locals are > within the site, and since hopefully nobody will invent IPv6 > NAT, filtering site-local addresses at the edge of the site > seems the appropriate solution to me. RFC 1918 has caused a disaster in most networks that want e2e out of the site because NAT is required. 1918 was a band-aid because of shortage of IPv4 address space and because we did not get IPv6 done quick enough. I want SLs removed precisely because of what I have seen from 1918. I am speaking of the user of private addresses not CIDR. That was a good idea but actually illegal with IPv4 IMHO. /jim > > My $0.02 > > 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 Mon Oct 28 09:53:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHro29011797; Mon, 28 Oct 2002 09:53:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SHroTN011796; Mon, 28 Oct 2002 09:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SHrk29011789 for ; Mon, 28 Oct 2002 09:53: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 g9SHruMq012322 for ; Mon, 28 Oct 2002 09:53:56 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14278 for ; Mon, 28 Oct 2002 09:53:50 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SHrlQ1026617; Mon, 28 Oct 2002 18:53:47 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 18:53:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C07@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: RE: Node Requirements issue 8 Date: Mon, 28 Oct 2002 18:53:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > DNS should not be a MUST. not all applications need to use it. > > Also, DNS is a separate service from IP. IP should not be > > thought to be dependent on DNS. > > I tend to agree with you. I see the following options: > > 1) For IPv6 nodes, DNS is a MUST if applications require it. => I dislike having a "MUST if". I think MUSTs should be unconditional. This option amounts to 2) below. > 2) For IPv6 nodes, support for DNS SHOULD be included, as many > applications require it. > 3) For IPv6 nodes, DNS SHOULD be included as DNS support is a > 'good thing.' > 4) For IPv6 nodes, DNS MAY be included. => I'm fine with 2,3 or 4. Hesham > > Any suggestions? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 10:11:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIBB29011957; Mon, 28 Oct 2002 10:11:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIBBmT011956; Mon, 28 Oct 2002 10:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIB729011949 for ; Mon, 28 Oct 2002 10:11:07 -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 g9SIBGbB026152 for ; Mon, 28 Oct 2002 10:11:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00323 for ; Mon, 28 Oct 2002 11:11:11 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SIB1020072; Mon, 28 Oct 2002 13:11:01 -0500 (EST) Message-Id: <200210281811.g9SIB1020072@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 17:56:21 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C02@Esealnt861.al.sw.ericsson.se> Date: Mon, 28 Oct 2002 13:11:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => I certainly didn't mean to suggest that the IETF > has an enforcement authority. I meant that this words > are used in cases where: if not followed, the protocol > will break. Therefore people generally follow them. if SLs are used in an environment where applications communicate across scope boundaries, reasonably-written applications (including apps using standard protocols) will break. therefore MUST/MUST NOT restrictions seem appropriate. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:21:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SILV29012043; Mon, 28 Oct 2002 10:21:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SILV0M012042; Mon, 28 Oct 2002 10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SILR29012035 for ; Mon, 28 Oct 2002 10:21:27 -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 g9SILbbB029833 for ; Mon, 28 Oct 2002 10:21:37 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03362 for ; Mon, 28 Oct 2002 10:21:31 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SILL020147; Mon, 28 Oct 2002 13:21:23 -0500 (EST) Message-Id: <200210281821.g9SILL020147@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 09:25:24 PST.") <2B81403386729140A3A899A8B39B046405E3C7@server2000> Date: Mon, 28 Oct 2002 13:21:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think this is a terrible idea. I can envision many situations where a > host would need both a site-local and a global address. please, elaborate. I haven't seen a good one yet. > > In fact, I am suggesting that all routers and hosts treat > > site-local unicast addresses exactly like global unicast > > addresses, and that we administratively restrict the use > > of site-local unicast addresses to non-globally-connected > > networks. > > I am comfortable with this. It's roughly what we do with RFC1918 > addresses today, and it has worked fine for many people. YES, this is what RFC 1918 _says_ - those addresses are for isolated networks only. And had those restrictions been adhered to I agree it would have worked fine for most people. NO, it's not roughly what we do with RFC 1918 addresses today - roughly what we do with them to day is use them as local addresses behind a NAT - a usage which is NOT consistent with RFC 1918 and which has caused huge problems. NO, this has not worked fine for many people - it's broken a large number of applications, and it has had a adverse effect on the network's ability to support apps. > Link-locals are > not routable, but site-locals are within the site, and since hopefully > nobody will invent IPv6 NAT, filtering site-local addresses at the edge > of the site seems the appropriate solution to me. you're missing the burden that having a mixture of SLs and globals puts on apps. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:25:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIPD29012091; Mon, 28 Oct 2002 10:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIPDRQ012090; Mon, 28 Oct 2002 10:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIPA29012083 for ; Mon, 28 Oct 2002 10:25:10 -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 g9SIPJbB001042 for ; Mon, 28 Oct 2002 10:25:19 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06397; Mon, 28 Oct 2002 10:25:13 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SIP1KV026281; Mon, 28 Oct 2002 19:25:01 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 19:25:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C08@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" Cc: "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 19:24:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > => I certainly didn't mean to suggest that the IETF > > has an enforcement authority. I meant that this words > > are used in cases where: if not followed, the protocol > > will break. Therefore people generally follow them. > > if SLs are used in an environment where applications communicate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > across scope boundaries, ^^^^^^^^^^^^^^^^^^^^^^^ => In other words, be careful how you use it. That's not a reason to deprecate the use of site-locals altogether. Hesham PS: I hope that a fundamental RFC like addrarch will be available soon!! If we keep this infinite loop going people will use 2373 and we'll end up in a lose lose situation. reasonably-written applications (including > apps using standard protocols) will break. > > therefore MUST/MUST NOT restrictions seem appropriate. > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:35:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIZR29012194; Mon, 28 Oct 2002 10:35:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIZRrp012193; Mon, 28 Oct 2002 10:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIZO29012186 for ; Mon, 28 Oct 2002 10:35:24 -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 g9SIZXMq027081 for ; Mon, 28 Oct 2002 10:35: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 pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15219 for ; Mon, 28 Oct 2002 11:35:28 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 10:35:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C8@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+ruUzUINCdEPqTr6CBzE6nRUKUAAAE4cA From: "Michel Py" To: "Keith Moore" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SIZO29012187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, In a nutshell, the point you are trying to make is that RFC1918 addresses are bad because NAT exists. I agree! (It's not like we had much of a choice anyway). Now, let's *not* generalize and say 1. site-local = RFC1918 2. site-local is bad because RFC1918 is bad. RFC1918 is not that bad without NAT, and lots of people use it without NAT as well. If I had any hint that IPv6 NAT will one day be invented and used like IPv4 NAT, I would not have this position, but this is not the case. >> I think this is a terrible idea. I can envision many >> situations where a host would need both a site-local >> and a global address. > please, elaborate. I haven't seen a good one yet. A somehow isolated subnet, where most hosts would have site-local only addresses, except for a gateway or proxy that would have both. > you're missing the burden that having a mixture of SLs > and globals puts on apps. You are missing the point, IMHO. This is not your call nor mine. Site-local addresses do exist, been there for long, some people will purposedly choose to use them in combination with global addresses. As of today, the address selection draft addresses use of site-local and global addresses simultaneously and I do not see a reason to change 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 Mon Oct 28 10:43:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIhv29012261; Mon, 28 Oct 2002 10:43:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIhvl0012260; Mon, 28 Oct 2002 10:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIhs29012253 for ; Mon, 28 Oct 2002 10:43:54 -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 g9SIi3bB008174 for ; Mon, 28 Oct 2002 10:44:03 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18396 for ; Mon, 28 Oct 2002 10:43:58 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA06639; Mon, 28 Oct 2002 10:43:41 -0800 (PST) Message-Id: <5.1.0.14.2.20021028133957.07a76250@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 13:44:07 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C08@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >PS: I hope that a fundamental RFC like addrarch will be >available soon!! If we keep this infinite loop going >people will use 2373 and we'll end up in a lose lose situation. This discussion should have no affect on the publication of the addr arch RFC, which is currently in the IESG awaiting approval for publication as a Draft Standard. We have quite a strong consensus that we need to keep the site-local address allocation in the addressing architecture, regardless of how/if we later restrict the use of these addresses. This discussion concerns what we should say about the _use_ of site-local unicast addresses in the scoped addressing architecture (which is still an I-D). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:49:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SInT29012340; Mon, 28 Oct 2002 10:49:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SInT4T012339; Mon, 28 Oct 2002 10:49:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SInP29012330 for ; Mon, 28 Oct 2002 10:49:25 -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 g9SInYMq001621 for ; Mon, 28 Oct 2002 10:49:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21872; Mon, 28 Oct 2002 10:49:29 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SInP020318; Mon, 28 Oct 2002 13:49:25 -0500 (EST) Message-Id: <200210281849.g9SInP020318@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 19:24:58 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C08@Esealnt861.al.sw.ericsson.se> Date: Mon, 28 Oct 2002 13:49:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > => I certainly didn't mean to suggest that the IETF > > > has an enforcement authority. I meant that this words > > > are used in cases where: if not followed, the protocol > > > will break. Therefore people generally follow them. > > > > if SLs are used in an environment where applications communicate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > across scope boundaries, > ^^^^^^^^^^^^^^^^^^^^^^^ > => In other words, be careful how you use it. That's not > a reason to deprecate the use of site-locals altogether. Their use should be confined to completely isolated networks so that they don't break applications. And yet this same constraint was imposed on RFC 1918 and it didn't stop RFC 1918 addresses from being misused. So yes, I think there's a compelling case for deprecating SLs entirely. But I'd be happy to hear of a way to impose a 1918-like restriction that would actually work this time around. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:58:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIwW29012517; Mon, 28 Oct 2002 10:58:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIwWYt012515; Mon, 28 Oct 2002 10:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIwP29012507 for ; Mon, 28 Oct 2002 10:58:25 -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 g9SIwYMq004779 for ; Mon, 28 Oct 2002 10:58:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00867 for ; Mon, 28 Oct 2002 11:58:29 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SIwI020343; Mon, 28 Oct 2002 13:58:18 -0500 (EST) Message-Id: <200210281858.g9SIwI020343@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 10:35:28 PST.") <2B81403386729140A3A899A8B39B046405E3C8@server2000> Date: Mon, 28 Oct 2002 13:58:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In a nutshell, the point you are trying to make is that RFC1918 > addresses are bad because NAT exists. no, that's missing the point. use of RFC 1918 addresses in a network that can also use global Internet addresses is harmful regardless of whether that connection to the global Internet uses NAT or whether it is merely via a router that filters traffic to/from the 1918 addresses. NAT is irrelevant to this particular problem. The problem is that in the presence of either 1918 or SLs applications have to deal with a mixture of scoped and global addresses without any good way of knowing whether such an address is valid (and whether it means the same thing) in the context of a particular node. > Now, let's *not* generalize and say > 1. site-local = RFC1918 > 2. site-local is bad because RFC1918 is bad. sorry - the two are quite similar, and they cause similar problems for apps. > >> I think this is a terrible idea. I can envision many > >> situations where a host would need both a site-local > >> and a global address. > > > please, elaborate. I haven't seen a good one yet. > > A somehow isolated subnet, where most hosts would have site-local only > addresses, except for a gateway or proxy that would have both. that's what 1918 was intended for. again, I don't have a huge problem with it as long as the apps don't have to deal with multiple scopes - but experience with 1918 predicts that that's exactly what will happen. > > you're missing the burden that having a mixture of SLs > > and globals puts on apps. > > You are missing the point, IMHO. This is not your call nor mine. > Site-local addresses do exist, been there for long, some people will > purposedly choose to use them in combination with global addresses. As > of today, the address selection draft addresses use of site-local and > global addresses simultaneously and I do not see a reason to change it. IETF's job is to try to explain what will make the network work well. Imposing constraints on the use of SLs will help the network work better. If SLs are encouraged as in the current draft it will degrade the ability of the network to support applications. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 10:58:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIwW29012516; Mon, 28 Oct 2002 10:58:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SIwVl2012514; Mon, 28 Oct 2002 10:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SIwO29012500 for ; Mon, 28 Oct 2002 10:58:24 -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 g9SIwYbB013482 for ; Mon, 28 Oct 2002 10:58:34 -0800 (PST) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05912 for ; Mon, 28 Oct 2002 11:58:28 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4P00DJ8GPF59@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 11:58:28 -0700 (MST) Received: from sun.com ([192.35.166.180]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4P00F5ZGPDAW@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 11:58:27 -0700 (MST) Date: Mon, 28 Oct 2002 10:58:49 -0800 From: Alain Durand Subject: Re: Limiting the Use of Site-Local In-reply-to: <2B81403386729140A3A899A8B39B046405E3C8@server2000> To: Michel Py Cc: ipng@sunroof.eng.sun.com Message-id: <4AE4D5FF-EAA7-11D6-A8C4-000393764158@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, October 28, 2002, at 10:35 AM, Michel Py wrote: > RFC1918 is not that bad without NAT, and lots of people use it without > NAT as well. If I had any hint that IPv6 NAT will one day be invented > and used like IPv4 NAT, I would not have this position, but this is not > the case. People start with an unconnected network, used RFC1918 style addresses, no NAT. Then, one day, they decide to connect to the Internet... ... and they realize it's "easier" (for some definition of easier) to use NAT than getting real address space and renumber their network. Now substitute IPv4 by IPv6 and you'll see IPv6 NAT. - 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 Oct 28 11:11:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJBa29012754; Mon, 28 Oct 2002 11:11:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJBa90012753; Mon, 28 Oct 2002 11:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJBX29012746 for ; Mon, 28 Oct 2002 11:11:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SJBgbB017918 for ; Mon, 28 Oct 2002 11:11:42 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15744 for ; Mon, 28 Oct 2002 12:11:36 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SJBOKV001478; Mon, 28 Oct 2002 20:11:24 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 20:11:24 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C0A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" Cc: "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 20:11:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > => I certainly didn't mean to suggest that the IETF > > > > has an enforcement authority. I meant that this words > > > > are used in cases where: if not followed, the protocol > > > > will break. Therefore people generally follow them. > > > > > > if SLs are used in an environment where applications > communicate > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > across scope boundaries, > > ^^^^^^^^^^^^^^^^^^^^^^^ > > => In other words, be careful how you use it. That's not > > a reason to deprecate the use of site-locals altogether. > > Their use should be confined to completely isolated > networks so that > they don't break applications. And yet this same > constraint was imposed > on RFC 1918 and it didn't stop RFC 1918 addresses from > being misused. > So yes, I think there's a compelling case for deprecating > SLs entirely. > But I'd be happy to hear of a way to impose a 1918-like restriction > that would actually work this time around. => It has a better chance of working this time because: - No one expects addresses to become a scarce resource in our lifetime anyway - I haven't seen any plans by ISPs to charge based on the number of addresses. So, I don't think it's quite the same problem as with RFC1918. Hesham > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:17:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJHJ29012841; Mon, 28 Oct 2002 11:17:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJHJXg012840; Mon, 28 Oct 2002 11:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJHF29012833 for ; Mon, 28 Oct 2002 11:17:15 -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 g9SJHPMq011801 for ; Mon, 28 Oct 2002 11:17:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10256 for ; Mon, 28 Oct 2002 11:17:19 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SJH9020420; Mon, 28 Oct 2002 14:17:09 -0500 (EST) Message-Id: <200210281917.g9SJH9020420@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 20:11:22 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C0A@Esealnt861.al.sw.ericsson.se> Date: Mon, 28 Oct 2002 14:17:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => It has a better chance of working this time because: > - No one expects addresses to become a scarce resource in our > lifetime anyway > > - I haven't seen any plans by ISPs to charge based on > the number of addresses. > > So, I don't think it's quite the same problem as with > RFC1918. > you're still missing the point. NAT doesn't cause this particular problem; use of limited scope addresses causes this problem regardless of whether NAT is used. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:21:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJLZ29012914; Mon, 28 Oct 2002 11:21:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJLZp6012913; Mon, 28 Oct 2002 11:21:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJLW29012906 for ; Mon, 28 Oct 2002 11:21:32 -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 g9SJLfMq013162 for ; Mon, 28 Oct 2002 11:21:41 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13125 for ; Mon, 28 Oct 2002 11:21:36 -0800 (PST) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9SJLHiZ006175 for ; Mon, 28 Oct 2002 14:21:18 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 28 Oct 2002 14:20:59 -0500 Message-ID: <3DBD8F1B.6060602@nc.rr.com> Date: Mon, 28 Oct 2002 14:25:15 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <4DA6EA82906FD511BE2F00508BCF0538044F0C0A@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman (EAB) wrote: > > > > > => I certainly didn't mean to suggest that the IETF > > > > > has an enforcement authority. I meant that this words > > > > > are used in cases where: if not followed, the protocol > > > > > will break. Therefore people generally follow them. > > > > > > > > if SLs are used in an environment where applications > > communicate > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > across scope boundaries, > > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > => In other words, be careful how you use it. That's not > > > a reason to deprecate the use of site-locals altogether. > > > > Their use should be confined to completely isolated > > networks so that > > they don't break applications. And yet this same > > constraint was imposed > > on RFC 1918 and it didn't stop RFC 1918 addresses from > > being misused. > > So yes, I think there's a compelling case for deprecating > > SLs entirely. > > But I'd be happy to hear of a way to impose a 1918-like restriction > > that would actually work this time around. > > => It has a better chance of working this time because: > - No one expects addresses to become a scarce resource in our > lifetime anyway > > - I haven't seen any plans by ISPs to charge based on > the number of addresses. > > So, I don't think it's quite the same problem as with > RFC1918. I agree that scarcity is not the issue. Rather, the end user sees it as simpler to slap a NAT in the network and connect rather than go through and renumber the network. 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 Oct 28 11:34:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJYM29013075; Mon, 28 Oct 2002 11:34:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJYLPV013074; Mon, 28 Oct 2002 11:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJYI29013067 for ; Mon, 28 Oct 2002 11:34: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 g9SJYSMq017498 for ; Mon, 28 Oct 2002 11:34:28 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23188; Mon, 28 Oct 2002 11:34:23 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA20517; Mon, 28 Oct 2002 11:34:12 -0800 (PST) Message-Id: <5.1.0.14.2.20021028142543.07a7cb60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 14:35:39 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , ipng@sunroof.eng.sun.com In-Reply-To: <200210281917.g9SJH9020420@astro.cs.utk.edu> References: <(Your message of "Mon, 28 Oct 2002 20:11:22 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C0A@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >you're still missing the point. NAT doesn't cause this particular >problem; use of limited scope addresses causes this problem regardless >of whether NAT is used. I wrote the following text for a document that I never published on the impact of IPv6 site-local addressing. I thought it might be useful to interject it here... Margaret x.x.x Similarities to NAT As you read through the problems caused by the use of IPv6 site- local addresses in globally connected networks, you will find that many of these problems are similar to the issues caused by IPv4 NAT. This is expected, as many NAT-related problems are caused by the use of private address spaces. Some of the complexities of IPv4 NAT are avoided by the fact that IPv6 SBRs do not translate site-local addresses into global addresses. Instead, traffic to and from site-local addresses is dropped at site boundaries, with an appropriate ICMP error message. SBRs do not modify addresses in forwarded IP headers, so the use of IPv6 site-local addresses does not conflict with end-to-end security or peer-to-peer communication at the IP layer. Unfortunately, dropping packets with site-local IPv6 source or destination addresses does not prevent site-local addresses from being sent outside of the local site in upper-layer protocol headers or data. This causes a set of problems for upper-layer protocols, some of which have been resolved in IPv4 NAT by the use of Application Level Gateways (ALGs). One possible solution to these problems would be to implement IPv6 ALGs on site-border routers, but this solution does not seem satisfactory, as it would require infrastructure updates for the deployment of new applications and would not work properly with end-to-end encryption. Without the deployment of IPv6 ALGs, however, IPv6 would require upper-layer protocols to make intelligent choices about when to exchange site-local addresses with other nodes and/or how to interpret site-local addresses that are received. This would require upper-layer applications to have knowledge of the site topology of the network, and it is not clear where or how this information can be obtained. IPv6 site-local addressing also introduces some problems that are not seen in networks that use IPv4 NAT, because it is possible for a single interface to have both global and site-local addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:38:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJcB29013159; Mon, 28 Oct 2002 11:38:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJcBr8013158; Mon, 28 Oct 2002 11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJc829013149 for ; Mon, 28 Oct 2002 11:38:08 -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 g9SJcHMq018777 for ; Mon, 28 Oct 2002 11:38:18 -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 MAA16401 for ; Mon, 28 Oct 2002 12:38:12 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9SJbwY04893; Mon, 28 Oct 2002 21:37:58 +0200 Date: Mon, 28 Oct 2002 21:37:57 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021028133957.07a76250@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Oct 2002, Margaret Wasserman wrote: > >PS: I hope that a fundamental RFC like addrarch will be > >available soon!! If we keep this infinite loop going > >people will use 2373 and we'll end up in a lose lose situation. > > This discussion should have no affect on the publication of > the addr arch RFC, which is currently in the IESG awaiting > approval for publication as a Draft Standard. No, I don't think so -- there's at least one point you missed, consider e.g.: 2.5.6 Local-Use IPv6 Unicast Addresses Routers must not forward any packets with site-local source or destination addresses outside of the site. This conflicts with the "treat as globals" stance. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:42:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJgk29013239; Mon, 28 Oct 2002 11:42:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJgk8g013238; Mon, 28 Oct 2002 11:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJgh29013231 for ; Mon, 28 Oct 2002 11:42:43 -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 g9SJgrbB027857 for ; Mon, 28 Oct 2002 11:42:53 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28649 for ; Mon, 28 Oct 2002 11:42:47 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SJgkQ1005819; Mon, 28 Oct 2002 20:42:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 20:42:46 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C0B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian Haberman'" , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 20:42:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => It has a better chance of working this time because: > > - No one expects addresses to become a scarce resource in our > > lifetime anyway > > > > - I haven't seen any plans by ISPs to charge based on > > the number of addresses. > > > > So, I don't think it's quite the same problem as with > > RFC1918. > > I agree that scarcity is not the issue. Rather, the end user > sees it as simpler to slap a NAT in the network and connect > rather than go through and renumber the network. => I completely agree that this is a possible scenario, but I also think that: 1. We will not eliminate stupidity or ignorance from the Internet. 2. The people that do that might have their reasons...I can't think of any and I wouldn't advice it, but...some people do. 3. Even if SLs were eliminated, what's going to stop someone from using _any_ bitstring for their internal addresses and when they want to connect to the Internet they will still throw a NATv6 on the edge. Why is this better? Deprecating site locals to aovid the scenario above is a futile attempt IMHO. Hesham > > Brian > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:48:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJm329013363; Mon, 28 Oct 2002 11:48:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJm2Dp013362; Mon, 28 Oct 2002 11:48:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJlx29013355 for ; Mon, 28 Oct 2002 11:47:59 -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 g9SJm9Mq021972 for ; Mon, 28 Oct 2002 11:48:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26314 for ; Mon, 28 Oct 2002 12:47:44 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Oct 2002 11:47:41 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 11:47:18 -0800 Message-ID: <057c01c27eba$d6069e50$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4AE4D5FF-EAA7-11D6-A8C4-000393764158@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SJm029013356 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a basic problem with this thread. We have a few people discussing fundamental changes in close to a vacuum. At best the result of this discussion should be a separate BCP, but before that happens operators of networks that actually use 1918 space need to be engaged to find out their requirements. The whole idea that SL should be revoked if a global is available is bogus. It is certainly reasonable for the manufacturer of light switches to only support SL/LL rather than potentially multiple global prefixes. There is no reason for those devices to interact across a scope boundary, so the peer nodes that may also need global access MUST keep their SL to interact in the limited scope. 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 Oct 28 11:49:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJmx29013386; Mon, 28 Oct 2002 11:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJmxnd013385; Mon, 28 Oct 2002 11:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJmt29013378 for ; Mon, 28 Oct 2002 11:48:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9SJn5Mq022337 for ; Mon, 28 Oct 2002 11:49:05 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29928 for ; Mon, 28 Oct 2002 11:49:00 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA01315; Mon, 28 Oct 2002 11:48:29 -0800 (PST) Message-Id: <5.1.0.14.2.20021028144824.029bfb30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 14:49:51 -0500 To: Pekka Savola From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , In-Reply-To: References: <5.1.0.14.2.20021028133957.07a76250@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >2.5.6 Local-Use IPv6 Unicast Addresses > > Routers must not forward any packets with site-local source or > destination addresses outside of the site. > >This conflicts with the "treat as globals" stance. Not really. If we define that site-local unicast addresses can only be used on non-globally-connected sites, there won't be any site- border routers that need to worry about this restriction. But, that doesn't make the restriction false. Site-local addresses should never be forward outside of a site. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 11:53:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJrI29013480; Mon, 28 Oct 2002 11:53:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SJrII9013479; Mon, 28 Oct 2002 11:53:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SJrF29013470 for ; Mon, 28 Oct 2002 11:53:15 -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 g9SJrOMq023894 for ; Mon, 28 Oct 2002 11:53:24 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29412; Mon, 28 Oct 2002 12:53:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9SJqYv05061; Mon, 28 Oct 2002 21:52:34 +0200 Date: Mon, 28 Oct 2002 21:52:34 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , "'sommerfeld@east.sun.com'" , "'Steven Blake'" , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021028144824.029bfb30@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Oct 2002, Margaret Wasserman wrote: > >2.5.6 Local-Use IPv6 Unicast Addresses > > > > Routers must not forward any packets with site-local source or > > destination addresses outside of the site. > > > >This conflicts with the "treat as globals" stance. > > Not really. If we define that site-local unicast addresses can only > be used on non-globally-connected sites, there won't be any site- > border routers that need to worry about this restriction. > > But, that doesn't make the restriction false. Site-local addresses > should never be forward outside of a site. And what about: Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes. I think if we want to go down the road discussed in this thread, I believe some (relatively minor) changes in addrarch could clarify many things. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 12:04:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SK4X29013643; Mon, 28 Oct 2002 12:04:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SK4X30013642; Mon, 28 Oct 2002 12:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SK4U29013635 for ; Mon, 28 Oct 2002 12:04: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 g9SK4ebB004624 for ; Mon, 28 Oct 2002 12:04:40 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09588 for ; Mon, 28 Oct 2002 12:04:33 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9SK4UE05168; Mon, 28 Oct 2002 22:04:30 +0200 Date: Mon, 28 Oct 2002 22:04:29 +0200 (EET) From: Pekka Savola To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local In-Reply-To: <057c01c27eba$d6069e50$4b194104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Oct 2002, Tony Hain wrote: [...] > The whole idea that SL should be revoked if a global is available is > bogus. It is certainly reasonable for the manufacturer of light switches > to only support SL/LL rather than potentially multiple global prefixes. > There is no reason for those devices to interact across a scope > boundary, so the peer nodes that may also need global access MUST keep > their SL to interact in the limited scope. This seems to be just primarily solving the "security and simple out-of-the-box configuration through site-locals" problem.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 12:52:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SKqI29013892; Mon, 28 Oct 2002 12:52:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SKqH9h013891; Mon, 28 Oct 2002 12:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SKqE29013884 for ; Mon, 28 Oct 2002 12:52: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 g9SKqObB018439 for ; Mon, 28 Oct 2002 12:52:24 -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 NAA03170 for ; Mon, 28 Oct 2002 13:52:17 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA08980; Mon, 28 Oct 2002 15:52:14 -0500 (EST) Date: Mon, 28 Oct 2002 15:52:14 -0500 (EST) From: Dan Lanciani Message-Id: <200210282052.PAA08980@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think it's great the folks are starting to consider the difficult problems associated with site-local addresses in particular and scoped addresses in general. In the past these have been glossed over with hand-waving arguments that scopes would ``just work'' with minimal application involvement and a little DNS magic. Before you try to solve the problems by effectively reducing scopes to a degenerate case of one and restricting site-local addresses to sites with no global addresses (or even with no external connectivity), please keep in mind that site-local addresses have been offered up as the solution to a number of other problems which themselves were difficult to hand-wave away. For example, the ability to have long-term tcp connections within a site in the face of global address renumbering has--given the lack of any protocol or application support for that renumbering--been pushed onto site-local addressing. (The problem is hardly confined to tcp, but that's the usual example cited.) Any language that reduces site-local addresses to second-class citizens (or, worse, implies that they should not be used concurrent with global addresses) will give stack and application vendors an excuse to fail to support such configurations. I don't think you want to open such a huge can of worms as it will entail revisiting every problem that has been ``resolved'' with an admonition to simply use site-local addresses. 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 Oct 28 13:00:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SL0t29013972; Mon, 28 Oct 2002 13:00:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SL0tjx013971; Mon, 28 Oct 2002 13:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SL0p29013964 for ; Mon, 28 Oct 2002 13:00:52 -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 g9SL11Mq018573 for ; Mon, 28 Oct 2002 13:01:01 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07428 for ; Mon, 28 Oct 2002 14:00:41 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9SKxmwo060920; Mon, 28 Oct 2002 15:59:48 -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.4) with ESMTP id g9SKwVbm263560; Mon, 28 Oct 2002 13:58:31 -0700 In-Reply-To: <057c01c27eba$d6069e50$4b194104@eagleswings> To: Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Sensitivity: 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 10/28/2002 03:58:21 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 10/28/2002 03:58:21 PM, Serialize complete at 10/28/2002 03:58:21 PM, S/MIME Sign failed at 10/28/2002 03:58:22 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/28/2002 14:58:31, Serialize complete at 10/28/2002 14:58:31 Message-ID: Date: Mon, 28 Oct 2002 16:58:29 -0400 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a basic problem with this thread. We have a few people discussing > fundamental changes in close to a vacuum. At best the result of this > discussion should be a separate BCP, but before that happens operators > of networks that actually use 1918 space need to be engaged to find out > their requirements. > > The whole idea that SL should be revoked if a global is available is > bogus. It is certainly reasonable for the manufacturer of light switches > to only support SL/LL rather than potentially multiple global prefixes. > There is no reason for those devices to interact across a scope > boundary, so the peer nodes that may also need global access MUST keep > their SL to interact in the limited scope. I thought global addresses could be used to communicate with peers using addresses of any scope as long as the interface over which the packet is sent is in the same scope zone as that peer. As such, a node with a global address does not require a site-local address to communicate with a node which has a site-local address but lacks a global address, as long as the two nodes reside within the same site. 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 Mon Oct 28 13:16:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLGt29014068; Mon, 28 Oct 2002 13:16:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SLGtNR014067; Mon, 28 Oct 2002 13:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLGq29014060 for ; Mon, 28 Oct 2002 13:16:52 -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 g9SLH1Mq023106 for ; Mon, 28 Oct 2002 13:17:01 -0800 (PST) Received: from mercury.lss.emc.com (mercury.lss.emc.com [168.159.40.77]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29856 for ; Mon, 28 Oct 2002 13:16:56 -0800 (PST) Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 16:16:39 -0500 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAE5C@srmoon> From: "sasson, shuki" To: "'Dan Lanciani'" , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 16:13:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, indeed scoping is a pain... specifically since it is not carried as a part of the address. In any case we should give an escape path out of this ambiguity to a "known" world. Meaning if a node is configured with a global addresses the global addresses will have higher priority being used as a source address over SL. Since the IPv6 transformation is expected to be evolution(vs. revolution) I believe the vast majority of the networks will choose to take this path. I know there is a draft in the work for this, and I believe this is what it says (correct me if I am wrong...). This way the vast majority of users knows there is a way to get over this problem... This is also solves the scoping problems for LL and multihome hosts. Shuki -----Original Message----- From: Dan Lanciani [mailto:ipng-incoming@danlan.com] Sent: Monday, October 28, 2002 3:52 PM To: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local I think it's great the folks are starting to consider the difficult problems associated with site-local addresses in particular and scoped addresses in general. In the past these have been glossed over with hand-waving arguments that scopes would ``just work'' with minimal application involvement and a little DNS magic. Before you try to solve the problems by effectively reducing scopes to a degenerate case of one and restricting site-local addresses to sites with no global addresses (or even with no external connectivity), please keep in mind that site-local addresses have been offered up as the solution to a number of other problems which themselves were difficult to hand-wave away. For example, the ability to have long-term tcp connections within a site in the face of global address renumbering has--given the lack of any protocol or application support for that renumbering--been pushed onto site-local addressing. (The problem is hardly confined to tcp, but that's the usual example cited.) Any language that reduces site-local addresses to second-class citizens (or, worse, implies that they should not be used concurrent with global addresses) will give stack and application vendors an excuse to fail to support such configurations. I don't think you want to open such a huge can of worms as it will entail revisiting every problem that has been ``resolved'' with an admonition to simply use site-local addresses. 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 Oct 28 13:18:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLIc29014094; Mon, 28 Oct 2002 13:18:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SLIcl6014093; Mon, 28 Oct 2002 13:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLIZ29014086 for ; Mon, 28 Oct 2002 13:18: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 g9SLIibB025917 for ; Mon, 28 Oct 2002 13:18:44 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25655 for ; Mon, 28 Oct 2002 13:18:39 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F2B1518E3 for ; Mon, 28 Oct 2002 16:18:35 -0500 (EST) Date: Mon, 28 Oct 2002 16:18:35 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-Reply-To: <200210281531.g9SFVw019147@astro.cs.utk.edu> References: <200210281531.g9SFVw019147@astro.cs.utk.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021028211836.F2B1518E3@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 28 Oct 2002 10:31:58 -0500, Keith Moore wrote: > > Distributed applications depend on consistent results from DNS, > regardless of where the query came from. Yep. RFC 2826 discusses this in some detail. > and what compelling purpose does all of this complexity serve? > none that I can see. Precisely. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 13:30:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLUv29014233; Mon, 28 Oct 2002 13:30:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SLUvkb014232; Mon, 28 Oct 2002 13:30:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLUs29014225 for ; Mon, 28 Oct 2002 13:30:54 -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 g9SLV3Mq027358 for ; Mon, 28 Oct 2002 13:31:03 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10074 for ; Mon, 28 Oct 2002 13:30:58 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA20256; Mon, 28 Oct 2002 13:30:50 -0800 (PST) Message-Id: <5.1.0.14.2.20021028162808.07a66420@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 16:32:11 -0500 To: From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <057c01c27eba$d6069e50$4b194104@eagleswings> References: <4AE4D5FF-EAA7-11D6-A8C4-000393764158@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, At 02:47 PM 10/28/02, Tony Hain wrote: >I have a basic problem with this thread. We have a few people discussing >fundamental changes in close to a vacuum. Obviously, a few people can't make a fundamental change to IPv6. But, we can propose a change, and discuss it on the WG (which should not resemble a vacuum). >The whole idea that SL should be revoked if a global is available is >bogus. It is certainly reasonable for the manufacturer of light switches >to only support SL/LL rather than potentially multiple global prefixes. What would a light switch do differently to support site-local as opposed to global? It still needs to get a prefix from a router and combine it with an IID using address autoconf. So, I don't understand what system requirements could be eliminated by refusing to support global prefixes. I've spent much of the last 7+ years working on IPv6 stacks for embedded systems, and they have all supported global addressing. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 13:47:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLlt29014474; Mon, 28 Oct 2002 13:47:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SLlt02014473; Mon, 28 Oct 2002 13:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLlp29014463 for ; Mon, 28 Oct 2002 13:47:51 -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 g9SLm1Mq002432 for ; Mon, 28 Oct 2002 13:48:01 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20690 for ; Mon, 28 Oct 2002 13:47:55 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0195818E8 for ; Mon, 28 Oct 2002 16:47:53 -0500 (EST) Date: Mon, 28 Oct 2002 16:47:53 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <200210282052.PAA08980@ss10.danlan.com> References: <200210282052.PAA08980@ss10.danlan.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021028214754.0195818E8@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 28 Oct 2002 15:52:14 -0500 (EST), Dan Lanciani wrote: > > Any language that reduces site-local addresses to second-class citizens (or, > worse, implies that they should not be used concurrent with global addresses) > will give stack and application vendors an excuse to fail to support such > configurations. I don't think you want to open such a huge can of worms as > it will entail revisiting every problem that has been ``resolved'' with an > admonition to simply use site-local addresses. If site-local was the answer, what were the questions? (No joke intended) Do you have a list? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 13:55:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLtQ29014633; Mon, 28 Oct 2002 13:55:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SLtPa7014632; Mon, 28 Oct 2002 13:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SLsN29014617 for ; Mon, 28 Oct 2002 13:54:53 -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 g9SLsXbB006479 for ; Mon, 28 Oct 2002 13:54:33 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24728 for ; Mon, 28 Oct 2002 13:54:27 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA06711; Mon, 28 Oct 2002 13:54:18 -0800 (PST) Message-Id: <5.1.0.14.2.20021028165333.07aa3e60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 16:55:47 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200210282052.PAA08980@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Any language that reduces site-local addresses to second-class citizens (or, >worse, implies that they should not be used concurrent with global addresses) >will give stack and application vendors an excuse to fail to support such >configurations. What do stack and application vendors need to do to support site-local addressing? And what makes you think that they are doing those things now? The majority of stack and application implementations with which I am familiar make no distinction at all between site-local address and globals. This is appropriate if site-locals will be used only on non-globally connected sites (so, effectively, site-local == global). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 14:02:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM2C29014773; Mon, 28 Oct 2002 14:02:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SM2AWw014772; Mon, 28 Oct 2002 14:02:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM2429014764 for ; Mon, 28 Oct 2002 14:02:04 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14074; Mon, 28 Oct 2002 17:02:13 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9SM2CrL010790; Mon, 28 Oct 2002 17:02:13 -0500 (EST) Message-Id: <200210282202.g9SM2CrL010790@thunk.east.sun.com> From: Bill Sommerfeld To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Mon, 28 Oct 2002 16:32:11 EST." <5.1.0.14.2.20021028162808.07a66420@mail.windriver.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 28 Oct 2002 17:02:12 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It is certainly reasonable for the manufacturer of light switches >to only support SL/LL rather than potentially multiple global >prefixes. So, my existing duct-tape-and-string home automation setup lets me turn on my porch light from work if I'm coming home late. Why would I upgrade it to an IPv6-based system with less functionality? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 14:04:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM4529014825; Mon, 28 Oct 2002 14:04:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SM45PC014824; Mon, 28 Oct 2002 14:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM4229014817 for ; Mon, 28 Oct 2002 14:04:02 -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 g9SM4BMq007479 for ; Mon, 28 Oct 2002 14:04:11 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12273 for ; Mon, 28 Oct 2002 15:04:06 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 14:04:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C9@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAAAFHuA From: "Michel Py" To: "Margaret Wasserman" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SM4229014818 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > I've spent much of the last 7+ years working on IPv6 > stacks for embedded systems, and they have all > supported global addressing. The issue is not the capability of the devices to support global addressing, but the desire of the network designer to configure a set of devices that specifically don't have access to the public address space. There are some military applications where devices have no business talking to the outside world. Control devices or sensors on a water distribution system or a power grid are another good example. These devices have no business whatsoever accessing the public internet, and it might be a requirement that the devices themselves have support for public addresses removed. 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 Oct 28 14:04:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM4D29014841; Mon, 28 Oct 2002 14:04:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SM4DKA014840; Mon, 28 Oct 2002 14:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SM4729014827 for ; Mon, 28 Oct 2002 14:04: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 g9SM4GbB009772 for ; Mon, 28 Oct 2002 14:04:16 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13041 for ; Mon, 28 Oct 2002 15:04:08 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Oct 2002 14:04:10 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 14:03:50 -0800 Message-ID: <058201c27ecd$e5aed170$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20021028162808.07a66420@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SM4829014828 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Hi Tony, > > At 02:47 PM 10/28/02, Tony Hain wrote: > >I have a basic problem with this thread. We have a few people > >discussing fundamental changes in close to a vacuum. > > Obviously, a few people can't make a fundamental change to > IPv6. But, we can propose a change, and discuss it on the WG > (which should not resemble a vacuum). > > >The whole idea that SL should be revoked if a global is available is > >bogus. It is certainly reasonable for the manufacturer of light > >switches to only support SL/LL rather than potentially > multiple global > >prefixes. > > What would a light switch do differently to support > site-local as opposed to global? It still needs to get a > prefix from a router and combine it with an IID using address > autoconf. So, I don't understand what system requirements > could be eliminated by refusing to support global prefixes. There is no difference in a SL vs. global prefix in the process of address creation in the stack. The real difference is that the simple device frequently is concerned about memory consumption, and that is minimized when it only has to support one SL & LL. The light switch could have a simple policy that the only prefix in the RA that it looks for is SL, which would minimize the management and make it more plug-n-play. I am not claiming I know of devices that look like this, but the opportunity exists the way things are currently defined. If there are multi-party applications that can't deal with scope boundaries, they are aware of that limitation and should be provided a mechanism to tell the stack SL is not an option for this socket. My real problem is that the thread is about preventing or restricting any use of the address format, simply because there is one valid case where it is not a good choice. The fact that there are other cases which are valid is being ignored. If someone wants to write a BCP that says SL should not be used for multi-party apps, fine, but this doc should not go further because other uses do not share the problem. Tony > > I've spent much of the last 7+ years working on IPv6 stacks > for embedded systems, and they have all supported global addressing. > > Margaret > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 14:33:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMXP29015228; Mon, 28 Oct 2002 14:33:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMXPPQ015227; Mon, 28 Oct 2002 14:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMXK29015220 for ; Mon, 28 Oct 2002 14:33:20 -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 g9SMXTbB018472 for ; Mon, 28 Oct 2002 14:33:29 -0800 (PST) Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03373 for ; Mon, 28 Oct 2002 15:33:24 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4P00CEKQNNT0@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 15:33:24 -0700 (MST) Received: from sun.com ([192.35.166.180]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4P00MQFQND6F@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 15:33:23 -0700 (MST) Date: Mon, 28 Oct 2002 14:33:35 -0800 From: Alain Durand Subject: Re: Limiting the Use of Site-Local In-reply-to: <2B81403386729140A3A899A8B39B046405E3C9@server2000> To: Michel Py Cc: ipng@sunroof.eng.sun.com Message-id: <4B805C26-EAC5-11D6-A8C4-000393764158@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, October 28, 2002, at 02:04 PM, Michel Py wrote: > There are some military applications where devices have no business > talking to the outside world. Control devices or sensors on a water > distribution system or a power grid are another good example. These > devices have no business whatsoever accessing the public internet, and > it might be a requirement that the devices themselves have support for > public addresses removed. > Oh... the old argument that NAT/private address brings security... - 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 Oct 28 14:45:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMjY29015580; Mon, 28 Oct 2002 14:45:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMjYxF015579; Mon, 28 Oct 2002 14:45:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMjU29015569 for ; Mon, 28 Oct 2002 14:45:31 -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 g9SMjeMq020295 for ; Mon, 28 Oct 2002 14:45:40 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18858 for ; Mon, 28 Oct 2002 15:45:35 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 14:45:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD267@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+0illfnT9ow+FQqeOlQvdIqoGUwAAVcRA From: "Michel Py" To: "Alain Durand" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SMjV29015570 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alain Durand wrote: > Oh... the old argument that NAT/private address > brings security... Go tell that to people that write requirements, especially the ones that work for the government, and when you have convinced them get back to us, ok? 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 Oct 28 14:46:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMk729015608; Mon, 28 Oct 2002 14:46:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMk707015607; Mon, 28 Oct 2002 14:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMk329015597 for ; Mon, 28 Oct 2002 14:46:03 -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 g9SMkCMq020473 for ; Mon, 28 Oct 2002 14:46:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05526 for ; Mon, 28 Oct 2002 15:46:06 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 14:46:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3CB@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAABO/Tg From: "Michel Py" To: "Margaret Wasserman" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SMk329015598 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > What would a light switch do differently to support > site-local as opposed to global? It still needs to > get a prefix from a router and combine it with an IID > using address autoconf. So, I don't understand what > system requirements could be eliminated by refusing > to support global prefixes. There is a matter of _implementing_ system requirements, not eliminating them. Let's talk about an airplane's IPv6 internal systems. There will be a requirement that the rudder's embedded controller reacts to site-local only, just in case a bozo mixes up something. OTOH, the NAV computer does need to talk to the outside word to extract weather or other in-flight dynamic data and to report to ground. All that stuff is displayed simultaneously on the glass cockpit CRTs, so at some point there is one computer in the plane that has access simultaneously to external data and to internal data. Now, explain me how you design that network (the plane) with deprecating site-locals when global addresses are present. Modern plane designs are multiple redundant networks that carry data for almost all of the plane's devices. 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 Oct 28 14:48:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMmP29015694; Mon, 28 Oct 2002 14:48:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMmPJR015693; Mon, 28 Oct 2002 14:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMmG29015683 for ; Mon, 28 Oct 2002 14:48:16 -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 g9SMmPbB023264 for ; Mon, 28 Oct 2002 14:48:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11312; Mon, 28 Oct 2002 15:48:19 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SMmH021761; Mon, 28 Oct 2002 17:48:17 -0500 (EST) Message-Id: <200210282248.g9SMmH021761@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: sommerfeld@east.sun.com cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 17:02:12 EST.") <200210282202.g9SM2CrL010790@thunk.east.sun.com> Date: Mon, 28 Oct 2002 17:48:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >It is certainly reasonable for the manufacturer of light switches > >to only support SL/LL rather than potentially multiple global > >prefixes. > > So, my existing duct-tape-and-string home automation setup lets me > turn on my porch light from work if I'm coming home late. Why would I > upgrade it to an IPv6-based system with less functionality? yeah, that was essentially going to be my question - why would I want to network my light switches, thermostat, dehumidifier, etc. unless doing so would allow me to access them from anywhere on the net? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 14:48:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMmc29015720; Mon, 28 Oct 2002 14:48:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMmbIc015718; Mon, 28 Oct 2002 14:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMmV29015702 for ; Mon, 28 Oct 2002 14:48:31 -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 g9SMmeMq021231 for ; Mon, 28 Oct 2002 14:48:40 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11462 for ; Mon, 28 Oct 2002 15:48:35 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA17069; Mon, 28 Oct 2002 14:48:25 -0800 (PST) Message-Id: <5.1.0.14.2.20021028174847.07aa3d80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 17:49:50 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C9@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >There are some military applications where devices have no business >talking to the outside world. Control devices or sensors on a water >distribution system or a power grid are another good example. These >devices have no business whatsoever accessing the public internet, and >it might be a requirement that the devices themselves have support for >public addresses removed. Private addressing does not provide any time of security that cannot be obtained (and more easily, in most cases) by appropriate configuration of firewalls or filters on routers. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 14:51:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMp329015916; Mon, 28 Oct 2002 14:51:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMp3cT015908; Mon, 28 Oct 2002 14:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMow29015894 for ; Mon, 28 Oct 2002 14:50:58 -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 g9SMp7bB026483 for ; Mon, 28 Oct 2002 14:51:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13163 for ; Mon, 28 Oct 2002 15:51:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SMor021791; Mon, 28 Oct 2002 17:50:53 -0500 (EST) Message-Id: <200210282250.g9SMor021791@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 14:04:07 PST.") <2B81403386729140A3A899A8B39B046405E3C9@server2000> Date: Mon, 28 Oct 2002 17:50:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The issue is not the capability of the devices to support global > addressing, but the desire of the network designer to configure a set of > devices that specifically don't have access to the public address space. the device designer has absolutely no business assuming that "site-local" threats are different than "global" ones. otoh, if the network designer wants to impose such constraints, packet filtering on global addresses is far more flexible and foolproof. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 14:51:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMpm29015977; Mon, 28 Oct 2002 14:51:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMplrX015974; Mon, 28 Oct 2002 14:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMpi29015967 for ; Mon, 28 Oct 2002 14:51:44 -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 g9SMpsMq022505 for ; Mon, 28 Oct 2002 14:51:54 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29387 for ; Mon, 28 Oct 2002 14:51:48 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA20826; Mon, 28 Oct 2002 14:51:40 -0800 (PST) Message-Id: <5.1.0.14.2.20021028175130.07aa1d90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 17:53:08 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3CB@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are these planes currently implemented using IPv4 RFC 1918 addresses? And, just for the record, I have not advocated automatically deprecating site-locals when global addresses are present. I have advocated administratively constraining site-local unicast addressing to non-globally-connected networks. Margaret At 05:46 PM 10/28/02, Michel Py wrote: >Margaret, > > > What would a light switch do differently to support > > site-local as opposed to global? It still needs to > > get a prefix from a router and combine it with an IID > > using address autoconf. So, I don't understand what > > system requirements could be eliminated by refusing > > to support global prefixes. > >There is a matter of _implementing_ system requirements, not eliminating >them. > >Let's talk about an airplane's IPv6 internal systems. There will be a >requirement that the rudder's embedded controller reacts to site-local >only, just in case a bozo mixes up something. OTOH, the NAV computer >does need to talk to the outside word to extract weather or other >in-flight dynamic data and to report to ground. > >All that stuff is displayed simultaneously on the glass cockpit CRTs, so >at some point there is one computer in the plane that has access >simultaneously to external data and to internal data. > >Now, explain me how you design that network (the plane) with deprecating >site-locals when global addresses are present. Modern plane designs are >multiple redundant networks that carry data for almost all of the >plane's devices. > >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 Mon Oct 28 14:58:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMwS29016401; Mon, 28 Oct 2002 14:58:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SMwSOv016400; Mon, 28 Oct 2002 14:58:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SMwO29016393 for ; Mon, 28 Oct 2002 14:58:24 -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 g9SMwXMq024598 for ; Mon, 28 Oct 2002 14:58:33 -0800 (PST) Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26149 for ; Mon, 28 Oct 2002 15:58:28 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4P00C42RTDT0@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 15:58:28 -0700 (MST) Received: from sun.com ([192.35.166.180]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4P00M1ZRTB6F@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 28 Oct 2002 15:58:25 -0700 (MST) Date: Mon, 28 Oct 2002 14:58:47 -0800 From: Alain Durand Subject: Re: Limiting the Use of Site-Local In-reply-to: <2B81403386729140A3A899A8B39B04640BD267@server2000> To: Michel Py Cc: ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, October 28, 2002, at 02:45 PM, Michel Py wrote: >> Alain Durand wrote: >> Oh... the old argument that NAT/private address >> brings security... > > Go tell that to people that write requirements, especially the ones > that > work for the government, and when you have convinced them get back to > us, ok? I thought we were trying to solve _technical_ problems. As I was wrong, I'll shut up. - 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 Oct 28 15:04:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN4X29016763; Mon, 28 Oct 2002 15:04:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SN4XqB016762; Mon, 28 Oct 2002 15:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN4Q29016749 for ; Mon, 28 Oct 2002 15:04: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 g9SN4ZMq026600 for ; Mon, 28 Oct 2002 15:04:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13179 for ; Mon, 28 Oct 2002 16:03:23 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SMxs021811; Mon, 28 Oct 2002 17:59:54 -0500 (EST) Message-Id: <200210282259.g9SMxs021811@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 14:03:50 PST.") <058201c27ecd$e5aed170$4b194104@eagleswings> Date: Mon, 28 Oct 2002 17:59:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no difference in a SL vs. global prefix in the process of > address creation in the stack. The real difference is that the simple > device frequently is concerned about memory consumption, and that is > minimized when it only has to support one SL & LL. The light switch > could have a simple policy that the only prefix in the RA that it looks > for is SL, which would minimize the management and make it more > plug-n-play. such a policy would also make it dysfunctional. it's completely bogus for such devices to impose constraints on how a network is designed. if a device is only going to recognize one RA prefix, it should probably be the shortest prefix that it sees. > I am not claiming I know of devices that look like this, but the > opportunity exists the way things are currently defined. If there are > multi-party applications that can't deal with scope boundaries, they are > aware of that limitation and should be provided a mechanism to tell the > stack SL is not an option for this socket. oh right, so we need to configure each application to be aware of network topology to know when to use and when not to use SL. > My real problem is that the thread is about preventing or restricting > any use of the address format, simply because there is one valid case > where it is not a good choice. so far there is at most one case where it is a good choice - providing a way for local connections to survive renumbering. and there are almost certainly better ways to solve that problem - defining explicit values for minimum time between renumberings and maximum time that a connection should be expected to stay up would be a good start, and they wouldn't be specific to local connections. > The fact that there are other cases which are valid is being ignored. we're still waiting to hear about them. > If someone wants to write a BCP that says SL > should not be used for multi-party apps, fine, but this doc should not > go further because other uses do not share the problem. no, it's the other way around. if someone wants to impose the constraint that large portions of the network should only support client-server apps then they need to bear the burden of convincing the rest of us as to why it's in the best interests of the Internet to have such a constraint. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 15:07:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN7k29016946; Mon, 28 Oct 2002 15:07:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SN7khw016945; Mon, 28 Oct 2002 15:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN7h29016936 for ; Mon, 28 Oct 2002 15:07: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 g9SN7qbB005449 for ; Mon, 28 Oct 2002 15:07:52 -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 QAA23293 for ; Mon, 28 Oct 2002 16:07:46 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA01692; Mon, 28 Oct 2002 15:07:37 -0800 (PST) Message-Id: <5.1.0.14.2.20021028180615.07aafcc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 18:08:43 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210282259.g9SMxs021811@astro.cs.utk.edu> References: <(Your message of "Mon, 28 Oct 2002 14:03:50 PST.") <058201c27ecd$e5aed170$4b194104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >if a device is only going to recognize one RA prefix, it should >probably be the shortest prefix that it sees. Or, since all prefixes are 64-bits long, it should recognize the first prefix it sees. >so far there is at most one case where it is a good choice - >providing a way for local connections to survive renumbering. >and there are almost certainly better ways to solve that problem - >defining explicit values for minimum time between renumberings >and maximum time that a connection should be expected to stay >up would be a good start, and they wouldn't be specific to local >connections. I have never understood the emphasis on helping local long-lived connections survive renumbering. There are a plethora of other events that can cause a long-lived connection to drop, so applications already have to be written to re-establish their long-lived connections if they go away. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 15:09:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN9E29017034; Mon, 28 Oct 2002 15:09:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SN9EJ4017032; Mon, 28 Oct 2002 15:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SN9929017022 for ; Mon, 28 Oct 2002 15:09:09 -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 g9SN9IbB005914 for ; Mon, 28 Oct 2002 15:09:18 -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 QAA19191 for ; Mon, 28 Oct 2002 16:09:11 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA02720; Mon, 28 Oct 2002 15:08:58 -0800 (PST) Message-Id: <5.1.0.14.2.20021028180914.07aab050@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 18:10:19 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Alain Durand" , In-Reply-To: <2B81403386729140A3A899A8B39B04640BD267@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm working on it... :-) Seriously, we have an opportunity, with the introduction of IPv6, to advocate new ways of doing things on the new network. Just because people have been doing something one (bad) way in the past, doesn't mean that we should advocate that approach in IPv6. Margaret At 05:45 PM 10/28/02, Michel Py wrote: > > Alain Durand wrote: > > Oh... the old argument that NAT/private address > > brings security... > >Go tell that to people that write requirements, especially the ones that >work for the government, and when you have convinced them get back to >us, ok? > >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 Mon Oct 28 15:21:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNLT29017479; Mon, 28 Oct 2002 15:21:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SNLTES017478; Mon, 28 Oct 2002 15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNLP29017471 for ; Mon, 28 Oct 2002 15:21:25 -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 g9SNLZbB009627 for ; Mon, 28 Oct 2002 15:21:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15528 for ; Mon, 28 Oct 2002 15:21:29 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9SNLJ021892; Mon, 28 Oct 2002 18:21:19 -0500 (EST) Message-Id: <200210282321.g9SNLJ021892@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 18:08:43 EST.") <5.1.0.14.2.20021028180615.07aafcc0@mail.windriver.com> Date: Mon, 28 Oct 2002 18:21:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have never understood the emphasis on helping local long-lived > connections survive renumbering. There are a plethora of other > events that can cause a long-lived connection to drop, so applications > already have to be written to re-establish their long-lived connections > if they go away. it depends on how often you think renumbering will be necessary relative to those other events. with backup power and reasonable operating systems, there's no reason to not expect connections to stay up (on average) for several weeks or even months. at present few applications are capable of recovering from address changes. the ones that are tend to be those that don't expect to connect for a long time anyway and those that interact directly with a human user who can initiate recovery. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 15:28:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNSD29017633; Mon, 28 Oct 2002 15:28:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SNSD7d017632; Mon, 28 Oct 2002 15:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNS929017622 for ; Mon, 28 Oct 2002 15:28:09 -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 g9SNSIbB011495 for ; Mon, 28 Oct 2002 15:28:19 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01417 for ; Mon, 28 Oct 2002 16:27:46 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Oct 2002 15:27:44 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 15:27:21 -0800 Message-ID: <059401c27ed9$922b7600$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210282259.g9SMxs021811@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SNSA29017623 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk moore@cs.utk.edu wrote: > ... > such a policy would also make it dysfunctional. it's > completely bogus for such devices to impose constraints on > how a network is designed. I am talking about default. If you want to change the policy to allow global access you should be able to do so, but there is no reason we should create an open dos problem when we don't have to. > > if a device is only going to recognize one RA prefix, it should > probably be the shortest prefix that it sees. Since they are all /64, that doesn't cut it. > > ... > oh right, so we need to configure each application to be > aware of network topology to know when to use and when not to use SL. Your input channel was shut down long ago. I was not arguing that the app know about network topology, just that it is aware of its own ability to deal with scope boundaries or not. If an app knows there are failure modes when crossing scope boundaries, it should have an option that prevents it from getting into that state. This is nothing more than a flag that says 'this socket must be considered global scope'. > > ... > so far there is at most one case where it is a good choice - > providing a way for local connections to survive renumbering. > and there are almost certainly better ways to solve that > problem - defining explicit values for minimum time between > renumberings and maximum time that a connection should be > expected to stay up would be a good start, and they wouldn't > be specific to local connections. > > > The fact that there are other cases which are valid is > being ignored. > > we're still waiting to hear about them. Your input channel is off. Despite the validity of the assumption, network managers want the ability to have some devices addressed in a space that can't be globally routed. The kinds of apps you are worried about don't apply. > > > If someone wants to write a BCP that says SL > > should not be used for multi-party apps, fine, but this doc > should not > > go further because other uses do not share the problem. > > no, it's the other way around. if someone wants to impose > the constraint that large portions of the network should only > support client-server apps then they need to bear the burden > of convincing the rest of us as to why it's in the best > interests of the Internet to have such a constraint. Peer-to-peer apps can use SL, as long as they are 2 party. When an app is willing to deal with more than 2 parties, it knows that and should have a means to refuse SL addresses if there is an alternative. 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 Oct 28 15:52:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNqD29018162; Mon, 28 Oct 2002 15:52:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SNqDrS018161; Mon, 28 Oct 2002 15:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNqA29018154 for ; Mon, 28 Oct 2002 15:52:10 -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 g9SNqKbB018824 for ; Mon, 28 Oct 2002 15:52:20 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21769 for ; Mon, 28 Oct 2002 15:52:14 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id BE5BA3B371 for ; Tue, 29 Oct 2002 10:52:11 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: ipng@sunroof.eng.sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE974B@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE974B@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 29 Oct 2002 10:52:11 +1100 Message-Id: <1035849132.7840.22.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, On Tue, 2002-10-29 at 04:42, Bound, Jim wrote: > Michael, > > Comments below. > > /jim > [Have you ever seen the rain coming down on a sunny day] > > > > > > Margaret, > > > > > Besides, it would be possible (although perhaps not > > > adviseable) to enforce this restriction. Nodes could immediately > > > deprecate site-local addresses whenever a global address is > > > configured. > > > > I think this is a terrible idea. I can envision many > > situations where a host would need both a site-local and a > > global address. > > I think this is a wonderful idea and would like to see it applied to src > address selection as MUST. > I agree. When I first put NAT in place for a customer (way back in 1995), I thought it was great ... until we tried to push Netbios packets through the NAT device, which it didn't understand. It was only after understanding what was happening did I realise the issues with NAT, at which point it was too late. The problem with NAT today is that it appears to work, and appears to work well. It is only getting "better" as more and more application handing code is put in NAT devices. By the time you find its limitations, it can be too costly to replace, either in terms of time, money, or just trying to motivate the "powers that be". I'd hate for the same thing to happen with SL under IPv6. While a number of people are posting to this list showing how Site Locals could work in conjunction with Globals, I think the question is just because SLs could work with Globals, _should_ they work with Globals ? In my experience, most network admins today tend to have a view that if it appears to be working, it must be ok to use it that way. I fear that SLs and Global combinations will fit into this category. Non-obvious reasons to avoid it just aren't a factor. I've met very few network admins that have ever read BCPs, let alone know they exist. I'd like to see the combination of SLs and Globals fail as per Margaret's suggestion. If necessary an override switch could be put in the device to disable this behaviour. At least this would provide a higher hurdle for less informed net admins to jump when trying to implement something that isn't the best thing for their network. Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 15:58:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNwK29018275; Mon, 28 Oct 2002 15:58:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9SNwKmp018274; Mon, 28 Oct 2002 15:58:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9SNwE29018261 for ; Mon, 28 Oct 2002 15:58:14 -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 g9SNwNbB020580 for ; Mon, 28 Oct 2002 15:58:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26748 for ; Mon, 28 Oct 2002 16:58:18 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 15:58:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3CC@server2000> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+1EMZOJjqq4j+Qka9q4mqww8hUwAATg6g From: "Michel Py" To: "Margaret Wasserman" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9SNwF29018262 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > Private addressing does not provide any time of security > that cannot be obtained (and more easily, in most cases) > by appropriate configuration of firewalls or filters on > routers. Mmmm. Maybe you can share how you access from the outside a system that has a site-local only address, without installing IPv6 NAT or some other proxy mechanism, when the edge device that you have compromised boots from flash that happens to physically write-protected? You can't put much code in the NVRAM that holds the config, given that you actually found how to execute code from there. There are lots of things that can provide security. Among them: paint. There are places where if you insert a red disk canister into a green computer, you get jailed and you could get shot. We had this discussion before, do we need to have it again? Although private addresses alone don't do much for security, there actually are _some_ situations where incorporating local addresses brings one more layer of things that needs to be hacked, which is good for security. What you are telling me is that there is no need to color-code disks in an underground secure facility where you need to clear three different layers of doors with traps and armored guards that strip search. What I'm telling you is that when one actually runs such a facility, one actually paints certain things in certain colors, even though one knows that the fact that the disk is red will not deter the determined spy to put it in a green computer. But it will deter most of the staff that wants to email the word file home to work there. > Are these planes currently implemented using IPv4 RFC > 1918 addresses? None that I have seen myself. Proprietary protocols, and it costs a lot. There are some cost reasons to move some systems to stuff that could be built with off-the-shelf items. 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 Oct 28 16:13:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Dn29018686; Mon, 28 Oct 2002 16:13:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0Dn1C018685; Mon, 28 Oct 2002 16:13:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Dj29018675 for ; Mon, 28 Oct 2002 16:13:45 -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 g9T0DsMq018016 for ; Mon, 28 Oct 2002 16:13:54 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12985 for ; Mon, 28 Oct 2002 16:13:49 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T0Dh021987; Mon, 28 Oct 2002 19:13:43 -0500 (EST) Message-Id: <200210290013.g9T0Dh021987@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 15:27:21 PST.") <059401c27ed9$922b7600$4b194104@eagleswings> Date: Mon, 28 Oct 2002 19:13:43 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... > > such a policy would also make it dysfunctional. it's=20 > > completely bogus for such devices to impose constraints on=20 > > how a network is designed. > > I am talking about default. If you want to change the policy to allow > global access you should be able to do so, but there is no reason we > should create an open dos problem when we don't have to. so what you are saying is that IETF should legitimize the idea that security scopes and network topology coincide. we *know* this is unwise. > > oh right, so we need to configure each application to be > > aware of network topology to know when to use and when not to use SL. > > Your input channel was shut down long ago. I was not arguing that the > app know about network topology, just that it is aware of its own > ability to deal with scope boundaries or not. If an app knows there are > failure modes when crossing scope boundaries, it should have an option > that prevents it from getting into that state. This is nothing more than > a flag that says 'this socket must be considered global scope'. just saying "apps that can't deal with SLs shouldn't use SLs" doesn't work because sites that use SLs will expect that apps work with SLs, and that global addressess aren't needed. there's no way that an "option" will keep the app from failing in that scenario - at best the app can try to detect the reason for the failure. even then, an explanation of the form "this app failed because it couldn't communicate between node Z1 and node Q3 because Q3 seems to only have site local addresses" isn't likely to cut it - the customer will demand that the app support communication with SLs only to later find out that this still doesn't help because Z1 and Q3 (or perhaps a different pair of nodes) don't share a common scope - meanwhile the app has acquired 10k more lines of code and its behavior has become less predictable. and the customer will then demand that the app support internal addressing and routing, because for some reason the network addresing plan is deemed to be carved in stone - even though it was based on a flawed design - and the app isn't. SLs are a lot like A6 records - they will work fine *if* you understand the constraints. but the constraints are even hard for IETF people to grasp. we're better off without both. as for *my* input channel... how many distributed applications have *you* tried to patch to deal with scoped addresses? > Despite the validity of the assumption, > network managers want the ability to have some devices addressed in a > space that can't be globally routed. just because newtork managers want something doesn't mean that IETF should complicate everyone's lives by giving it to them. large numbers of network managers have been deluded by snake oil salesmen. if IETF starts catering to salesmen-induced delusions we may as well go back to using carrier pigeons - since it will work better than the Internet. > The kinds of apps you are worried about don't apply. and who are you to say that (just to take one example) SIP doesn't need to be able to complete calls across scope boundaries? > Peer-to-peer apps can use SL, as long as they are 2 party. When an app > is willing to deal with more than 2 parties, it knows that and should > have a means to refuse SL addresses if there is an alternative. easily done, *if* there is an alternative. but if the alternatives exist, why bother with SL at all? it's easier to implement a sane filtering policy with globals. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 16:20:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0KL29018836; Mon, 28 Oct 2002 16:20:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0KKdI018835; Mon, 28 Oct 2002 16:20:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0KH29018828 for ; Mon, 28 Oct 2002 16:20:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T0KQbB027416 for ; Mon, 28 Oct 2002 16:20:27 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08060 for ; Mon, 28 Oct 2002 17:20:20 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9T0JxBM025336; Tue, 29 Oct 2002 11:19:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210290019.g9T0JxBM025336@drugs.dv.isc.org> To: Keith Moore Cc: "Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Mon, 28 Oct 2002 13:58:18 CDT." <200210281858.g9SIwI020343@astro.cs.utk.edu> Date: Tue, 29 Oct 2002 11:19:59 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In a nutshell, the point you are trying to make is that RFC1918 > > addresses are bad because NAT exists. > > no, that's missing the point. use of RFC 1918 addresses in a network > that can also use global Internet addresses is harmful regardless of > whether that connection to the global Internet uses NAT or whether it > is merely via a router that filters traffic to/from the 1918 addresses. > > NAT is irrelevant to this particular problem. The problem is that > in the presence of either 1918 or SLs applications have to deal with > a mixture of scoped and global addresses without any good way of knowing > whether such an address is valid (and whether it means the same thing) > in the context of a particular node. Which just means that we need to provide a way for the application / library to return appropriate addresses. Make SL work rather than saying "kill them" or "don't put them in the DNS". I've already said how to put them in the DNS. It requires a new record but it will work and it will remove the need for two faced DNS unless the sites *wants* to use two faced DNS to hide the records. Site locals provide a solution for a certian problem space. They do create additional problems but they are not insolvable problems and are no different to the problems causes by LLs. You need a function that looks up names and returns addresses along with the scope_id. We have that in getaddrinfo(). You need a function that takes a address and a scope_id and returns the name. We don't have that but it is very easy to do that in the DNS if you want to privided you have a scope-id to scope-name function which is need. e.g. . PTR It's not zero-conf but sites will most probably never be zero-conf. e.g. foo.example.net. SA6 1080:0:0:0:8:800:200C:417A . foo.example.net. SA6 FE80:0:0:0:8:800:200C:417A my-site.example.net. foo.example.net. SA6 FEC0:0:0:0:8:800:200C:417A my-link.example.net. c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.1.ip6.arpa. ( PTR foo.example.net. ) c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.my-site.example.net. ( PTR foo.example.net. ) c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.my-link.example.net. ( PTR foo.example.net. ) and you have a local table that maps my-site.example.net and my-link.example.net to appropiate scope-id values. Now if you want to send address between applications in binary format just send SA6 rdata instead of AAAA rdata. Applications / libraries can filter out the addresses that are not useful to them if they want. Mark > > 2. site-local is bad because RFC1918 is bad. > > sorry - the two are quite similar, and they cause similar problems for apps. > > > >> and a global address. > > > > > please, elaborate. I haven't seen a good one yet. > > > > A somehow isolated subnet, where most hosts would have site-local only > > addresses, except for a gateway or proxy that would have both. > > that's what 1918 was intended for. again, I don't have a huge problem > with it as long as the apps don't have to deal with multiple scopes - > but experience with 1918 predicts that that's exactly what will happen. > > > > you're missing the burden that having a mixture of SLs > > > and globals puts on apps. > > > > You are missing the point, IMHO. This is not your call nor mine. > > Site-local addresses do exist, been there for long, some people will > > purposedly choose to use them in combination with global addresses. As > > of today, the address selection draft addresses use of site-local and > > global addresses simultaneously and I do not see a reason to change it. > > IETF's job is to try to explain what will make the network work well. > Imposing constraints on the use of SLs will help the network work better. > If SLs are encouraged as in the current draft it will degrade the ability > of the network to support applications. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 16:26:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Qf29019102; Mon, 28 Oct 2002 16:26:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0Qeom019101; Mon, 28 Oct 2002 16:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Qb29019094 for ; Mon, 28 Oct 2002 16:26:37 -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 g9T0QlbB029203 for ; Mon, 28 Oct 2002 16:26:47 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07434; Mon, 28 Oct 2002 17:26:38 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9T0QUBM025386; Tue, 29 Oct 2002 11:26:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210290026.g9T0QUBM025386@drugs.dv.isc.org> To: Alain Durand Cc: Michel Py , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Mon, 28 Oct 2002 10:58:49 -0800." <4AE4D5FF-EAA7-11D6-A8C4-000393764158@sun.com> Date: Tue, 29 Oct 2002 11:26:30 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > On Monday, October 28, 2002, at 10:35 AM, Michel Py wrote: > > > RFC1918 is not that bad without NAT, and lots of people use it without > > NAT as well. If I had any hint that IPv6 NAT will one day be invented > > and used like IPv4 NAT, I would not have this position, but this is not > > the case. > > People start with an unconnected network, used RFC1918 style addresses, > no NAT. Then, one day, they decide to connect to the Internet... > ... and they realize it's "easier" (for some definition of easier) > to use NAT than getting real address space and renumber their network. > Now substitute IPv4 by IPv6 and you'll see IPv6 NAT. > > - Alain. Except with SL you don't re-number. You just provide a additional global address. All your nodes continue to use there existing SL addresses. The routers advertise a new prefix. The nodes configure a new address and register it in the DNS and are done. This is a lot less painful that what is required to go from using RFC 1918 address to using global IPv4 addresses. Mark > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 16:32:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Wl29019268; Mon, 28 Oct 2002 16:32:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0Wlbo019265; Mon, 28 Oct 2002 16:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Wh29019257 for ; Mon, 28 Oct 2002 16:32:43 -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 g9T0WqbB001261 for ; Mon, 28 Oct 2002 16:32:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11470 for ; Mon, 28 Oct 2002 17:32:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T0VN022080; Mon, 28 Oct 2002 19:31:24 -0500 (EST) Message-Id: <200210290031.g9T0VN022080@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , "Michel Py" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 11:19:59 +1100.") <200210290019.g9T0JxBM025336@drugs.dv.isc.org> Date: Mon, 28 Oct 2002 19:31:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > In a nutshell, the point you are trying to make is that RFC1918 > > > addresses are bad because NAT exists. > > > > no, that's missing the point. use of RFC 1918 addresses in a network > > that can also use global Internet addresses is harmful regardless of > > whether that connection to the global Internet uses NAT or whether it > > is merely via a router that filters traffic to/from the 1918 addresses. > > > > NAT is irrelevant to this particular problem. The problem is that > > in the presence of either 1918 or SLs applications have to deal with > > a mixture of scoped and global addresses without any good way of knowing > > whether such an address is valid (and whether it means the same thing) > > in the context of a particular node. > > Which just means that we need to provide a way for the application / > library to return appropriate addresses. no, it doesn't solve the real problem. putting SLs in a separate space will keep existing apps from being confused by them, but it won't supply global addresses when they are needed, it won't provide a way for appst to recognize and deal with scope boundaries, and it won't stop sites from requiring apps to recogize the new addresses and use them even though they're a tremendous pain in the wazoo. and as I keep saying, DNS is just one example of an application that provides address referrals - are we going to impose the same amount of additional complexity on every app that does this? > Make SL work rather than > saying "kill them" or "don't put them in the DNS". the best way to make them "work" is to make them global. > Site locals provide a solution for a certian problem space. pray tell, what is that problem space? especially if you eliminate the bogus argument that they somehow provide security or relieve devices of the need to provide security. long-lived connections, perhaps. that's all I've seen so far. > They > do create additional problems but they are not insolvable problems > and are no different to the problems causes by LLs. LLs do cause similar problems. but at least LLs have a use case - bootstrapping, autoconfiguration, router and neighbor discovery, ad hoc networks. those are compelling enough that it makes sense to say "keep LLs but don't use LLs except for those specific cases". I'm still looking for a compelling case for SLs. > You need a function that looks up names and returns addresses along > with the scope_id. We have that in getaddrinfo(). You need a > function that takes a address and a scope_id and returns the name. and you need for apps to know which addresses work in which scopes, and to know which scopes each node can access, and to keep track of each node's scopes so that they'll know how to do referrals, and how to route messages across that maze of scopes. and to do that you need a global scope space. suddenly 128 bits isn't enough for an address any longer, because we also need a scope id to disambiguate scoped addresses. why don't we just make IPv7 with 256 bits of address, and assign 128 bits for a global scope id? are we having fun yet? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 16:33:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Xr29019321; Mon, 28 Oct 2002 16:33:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0Xrd4019320; Mon, 28 Oct 2002 16:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0Xn29019313 for ; Mon, 28 Oct 2002 16:33:49 -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 g9T0XwMq024435 for ; Mon, 28 Oct 2002 16:33:58 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11910 for ; Mon, 28 Oct 2002 17:33:53 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T0Xo022121; Mon, 28 Oct 2002 19:33:50 -0500 (EST) Message-Id: <200210290033.g9T0Xo022121@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Alain Durand" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 14:45:36 PST.") <2B81403386729140A3A899A8B39B04640BD267@server2000> Date: Mon, 28 Oct 2002 19:33:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk so you're arguing that we should abandon good judgement because some government bureaucrats who write requirements don't understand security? tell them to use IPv4. it's already too screwed up to fix. Keith > > Alain Durand wrote: > > Oh... the old argument that NAT/private address > > brings security... > > Go tell that to people that write requirements, especially the ones that > work for the government, and when you have convinced them get back to > us, ok? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 16:40:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0eA29019532; Mon, 28 Oct 2002 16:40:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0e9MY019531; Mon, 28 Oct 2002 16:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0e529019524 for ; Mon, 28 Oct 2002 16:40:05 -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 g9T0eFbB003057 for ; Mon, 28 Oct 2002 16:40:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17839 for ; Mon, 28 Oct 2002 17:40:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T0e3022185; Mon, 28 Oct 2002 19:40:03 -0500 (EST) Message-Id: <200210290040.g9T0e3022185@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 14:46:05 PST.") <2B81403386729140A3A899A8B39B046405E3CB@server2000> Date: Mon, 28 Oct 2002 19:40:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let's talk about an airplane's IPv6 internal systems. There will be a > requirement that the rudder's embedded controller reacts to site-local > only, just in case a bozo mixes up something. OTOH, the NAV computer > does need to talk to the outside word to extract weather or other > in-flight dynamic data and to report to ground. that's what packet filtering is for. nobody is saying that there's no need for filtering between networks. what we're saying is that having a single fixed partition of address space for this purpose is a really, really shortsighted and inflexible way of providing that - and one that drastically complicates applications. and given that far better solutions already exist, one that is totally unnecessary. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 16:44:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0iu29019661; Mon, 28 Oct 2002 16:44:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T0iu8w019660; Mon, 28 Oct 2002 16:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T0iq29019647 for ; Mon, 28 Oct 2002 16:44:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T0j2Mq027315 for ; Mon, 28 Oct 2002 16:45:02 -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 RAA11638 for ; Mon, 28 Oct 2002 17:44:56 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 16:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3CD@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+48oWcIWJSE72QAKTCTZB1EYGygAAB9wQ From: "Michel Py" To: "Keith Moore" Cc: "Margaret Wasserman" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T0ir29019651 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> Let's talk about an airplane's IPv6 internal systems. There will >> be a requirement that the rudder's embedded controller reacts >> to site-local only, just in case a bozo mixes up something. OTOH, >> the NAV computer does need to talk to the outside word to extract >> weather or other in-flight dynamic data and to report to ground. > Keith Moore wrote: > that's what packet filtering is for. Keith, you don't get my point. The requirement for site-local is because someone or something can mess up packet filtering. It is in *addition* of the packet filtering. In an airplane, one level of security does not take off. 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 Oct 28 17:03:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T13N29020008; Mon, 28 Oct 2002 17:03:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T13M6J020007; Mon, 28 Oct 2002 17:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T13I29020000 for ; Mon, 28 Oct 2002 17:03:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T13SbB009898 for ; Mon, 28 Oct 2002 17:03:28 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20769; Mon, 28 Oct 2002 18:03:22 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T125022413; Mon, 28 Oct 2002 20:02:05 -0500 (EST) Message-Id: <200210290102.g9T125022413@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Alain Durand , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 11:26:30 +1100.") <200210290026.g9T0QUBM025386@drugs.dv.isc.org> Date: Mon, 28 Oct 2002 20:02:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Except with SL you don't re-number. You just provide a additional global address. All your nodes continue to use there existing SL addresses. and your applications break when they talk to external nodes and they find that using SLs for referrals no longer works. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 17:03:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T13i29020018; Mon, 28 Oct 2002 17:03:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T13iMs020017; Mon, 28 Oct 2002 17:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T13d29020010 for ; Mon, 28 Oct 2002 17:03:39 -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 g9T13mbB009997 for ; Mon, 28 Oct 2002 17:03:48 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20978 for ; Mon, 28 Oct 2002 18:03:42 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T114022365; Mon, 28 Oct 2002 20:01:04 -0500 (EST) Message-Id: <200210290101.g9T114022365@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Margaret Wasserman" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 16:44:59 PST.") <2B81403386729140A3A899A8B39B046405E3CD@server2000> Date: Mon, 28 Oct 2002 20:01:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith, you don't get my point. The requirement for site-local is because > someone or something can mess up packet filtering. It is in *addition* > of the packet filtering. In an airplane, one level of security does not > take off. that's bogus. filtering SLs has exactly the same vulnerabilities as filtering globals or any other pattern of bits. some routers will have to filter SLs, others will have to pass them, so there is always the potential that this bit of configuration can be corrupted. you can put as many levels to filter globals based on prefix as you put to filter SLs, and at the same cost. actually this particular use of SL wouldn't bother me at all as long as you don't impose SLs on passengers or an external network - because almost none of this is going to use off-the-shelf hardware or software but it's also true that SLs don't give you additional security. nor do they make your job any easier. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 17:06:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T16e29020075; Mon, 28 Oct 2002 17:06:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T16d10020074; Mon, 28 Oct 2002 17:06:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T16a29020067 for ; Mon, 28 Oct 2002 17:06:36 -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 g9T16jMq003665 for ; Mon, 28 Oct 2002 17:06:46 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28662 for ; Mon, 28 Oct 2002 18:06:45 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA21195; Mon, 28 Oct 2002 17:06:17 -0800 (PST) Message-Id: <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 20:06:12 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Keith Moore" , , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3CD@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have heard several arguments for why people might like to use some sort of limited-scope addressing in special circumstances. I've also heard a couple of general benefits (long-lived connections and dubious security benefits). But, I haven't really heard any arguments that have swayed me from my original position. Private addressing causes significant complexities, and we don't know how to solve all of the problems that it causes for applications, DNS, routing protocols and network management protocols. Therefore, I don't think that we should define it as an inherent part of IPv6. There may be some significant advantages to private addressing, so I _do_ support the idea of an IRTF WG being formed to sort out the issues surrounding private addressing and make recommendations regarding what the IETF should/shouldn't standardize in this area. I also think that an IAB document in this area would be appropriate. But, I don't want to see us standardize a badly-thought-out private addressing scheme at the core of IPv6. In my opinion, there are three possible choices here: (1) Limit the scope of the IPv6 WG's problem, by forbidding the use of site-local addresses on globally-connected networks in the scoped addressing architecture. This would not preclude work in this area by other groups within the IETF/IRTF, and we could remove the restriction when the implications are fully understood. (2) Develop a complete solution for scoped unicast addressing within the IPv6 WG. This would include solving the problems they cause for all protocols/layers. (3) Define an IP-level solution for scoped addressing (similar to what is currently in the scoped addressing architecture), and consider all of the implications of that architecture on other protocols/layers to be someone else's problem. The first choice is both responsible and doable. I have deep concerns about the second choice, along two lines: (1) I think it is important that we stabilize and complete IPv6 quickly, as folks are widely implementing and deploying it, and (2) I don't know that we have the expertise (in the IPv6 WG or anywhere in the IETF, without further research) to solve these problems. And, in my opinion, the third choice (which is what we seem to be doing so far) is blatantly irresponsible. Are there people who want to argue for choices #2 and/or #3? Or are there other choices that I've left out? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 17:08:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T18O29020123; Mon, 28 Oct 2002 17:08:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T18OoD020122; Mon, 28 Oct 2002 17:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T18K29020112 for ; Mon, 28 Oct 2002 17:08:20 -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 g9T18TMq004077 for ; Mon, 28 Oct 2002 17:08:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29666 for ; Mon, 28 Oct 2002 17:08:24 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T15o022428; Mon, 28 Oct 2002 20:05:50 -0500 (EST) Message-Id: <200210290105.g9T15o022428@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 15:58:19 PST.") <2B81403386729140A3A899A8B39B046405E3CC@server2000> Date: Mon, 28 Oct 2002 20:05:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mmmm. Maybe you can share how you access from the outside a system that > has a site-local only address, without installing IPv6 NAT or some other > proxy mechanism, when the edge device that you have compromised boots > from flash that happens to physically write-protected? and maybe you can explain how you can access from the outside a system that has a global address but for which access is blocked using packet filters, whose configuration is write-protected in a similar manner? why is a packet filter for an SL address better than a packet filter for a prefix? it's not as if vanilla ciscos are going to be TSOed for use in transport class aircraft anyway. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 17:15:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T1F229020272; Mon, 28 Oct 2002 17:15:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T1F2xd020271; Mon, 28 Oct 2002 17:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T1Ew29020261 for ; Mon, 28 Oct 2002 17:14: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 g9T1F7bB012891 for ; Mon, 28 Oct 2002 17:15:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26249 for ; Mon, 28 Oct 2002 18:15:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T1CQ022499; Mon, 28 Oct 2002 20:12:26 -0500 (EST) Message-Id: <200210290112.g9T1CQ022499@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Michel Py" , "Keith Moore" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 20:06:12 EST.") <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> Date: Mon, 28 Oct 2002 20:12:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (1) Limit the scope of the IPv6 WG's problem, by forbidding the use of site-local addresses on globally-connected networks in the scoped addressing architecture. This would not preclude work in this area by other groups within the IETF/IRTF, and we could remove the restriction when the implications are fully understood. seems reasonable to me, as long as "globally-connected" includes any IP network that is connected (directly or indirectly) via IP to a network that is connected to the global IPv6 Internet. I also doubt we can ever "remove the restriction" in the sense that we expect apps that were built to treat all addresses as global to run when they're exposed to a mixture of global and scoped addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 17:32:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T1WJ29020447; Mon, 28 Oct 2002 17:32:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T1WJqA020446; Mon, 28 Oct 2002 17:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T1WG29020439 for ; Mon, 28 Oct 2002 17:32: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 g9T1WPbB017322 for ; Mon, 28 Oct 2002 17:32:25 -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 SAA04156 for ; Mon, 28 Oct 2002 18:32:20 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA06425; Mon, 28 Oct 2002 17:31:56 -0800 (PST) Message-Id: <5.1.0.14.2.20021028203014.07ab0840@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 20:32:00 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: "Michel Py" , "Keith Moore" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210290112.g9T1CQ022499@astro.cs.utk.edu> References: <(Your message of "Mon, 28 Oct 2002 20:06:12 EST.") <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >seems reasonable to me, as long as "globally-connected" includes >any IP network that is connected (directly or indirectly) via >IP to a network that is connected to the global IPv6 Internet. Sounds like an excellent definition to me. >I also doubt we can ever "remove the restriction" in the >sense that we expect apps that were built to treat all addresses >as global to run when they're exposed to a mixture of global >and scoped addresses. Correct. If we later introduce the concept of private addressing to IPv6, we would need to do it in a way that wouldn't break deployed apps. This might include things like the separate DNS record that Erik Nordmark proposed, and/or other IP-level mechanisms to prevent handing site-local addresses to applications that don't know how to deal with them. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 18:22:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T2Me29020682; Mon, 28 Oct 2002 18:22:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T2MeTX020681; Mon, 28 Oct 2002 18:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T2MZ29020674 for ; Mon, 28 Oct 2002 18:22: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 g9T2MebB028033 for ; Mon, 28 Oct 2002 18:22:44 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01897 for ; Mon, 28 Oct 2002 18:22:35 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA01478; Mon, 28 Oct 2002 18:22:23 -0800 (PST) Message-Id: <5.1.0.14.2.20021028212132.07abac00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 21:23:50 -0500 To: Mark.Andrews@isc.org From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: Keith Moore , "Michel Py" , ipng@sunroof.eng.sun.com In-Reply-To: <200210290019.g9T0JxBM025336@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mark, > I've already said how to put them in the DNS. It requires a new > record but it will work and it will remove the need for two faced > DNS unless the sites *wants* to use two faced DNS to hide the > records. I don't have enough DNS expertise to fully evaluate your idea, but it looks like an interesting possibility to resolve several problems with putting IPv6 site-local addresses in the DNS. Have you made this suggestion on any DNS-related groups, like dnsext, perhaps? It would be interesting to see if other DNS folks think that this makes sense. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 18:34:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T2Y129020749; Mon, 28 Oct 2002 18:34:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T2Y1Zo020748; Mon, 28 Oct 2002 18:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T2Xw29020741 for ; Mon, 28 Oct 2002 18:33:58 -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 g9T2Y7Mq027340 for ; Mon, 28 Oct 2002 18:34: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 patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06684 for ; Mon, 28 Oct 2002 19:34:01 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 18:34:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3CF@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+532yxCWeGhUaSfKTCtYzrR/nrQACuOXA From: "Michel Py" To: "Keith Moore" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T2Xw29020742 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Mmmm. Maybe you can share how you access from the outside a >> system that has a site-local only address, without installing >> IPv6 NAT or some other proxy mechanism, when the edge device >> that you have compromised boots from flash that happens to >> physically write-protected? > and maybe you can explain how you can access from the outside > a system that has a global address but for which access is > blocked using packet filters, whose configuration is write- > protected in a similar manner? Physically write-protected config? Obviously you don't realize what you just wrote. > it's not as if vanilla ciscos are going to be TSOed for use > in transport class aircraft anyway. Exactly the same as saying that vanilla PCs are not going to be used for Cisco gear. Look inside a Pix, one 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 Oct 28 19:17:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T3Hj29020886; Mon, 28 Oct 2002 19:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T3Hjrk020885; Mon, 28 Oct 2002 19:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T3Hg29020878 for ; Mon, 28 Oct 2002 19:17:42 -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 g9T3HpMq004844 for ; Mon, 28 Oct 2002 19:17:51 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14492 for ; Mon, 28 Oct 2002 20:17:45 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9T3HUBM026165; Tue, 29 Oct 2002 14:17:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210290317.g9T3HUBM026165@drugs.dv.isc.org> To: Margaret Wasserman Cc: Keith Moore , "Michel Py" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Mon, 28 Oct 2002 21:23:50 CDT." <5.1.0.14.2.20021028212132.07abac00@mail.windriver.com> Date: Tue, 29 Oct 2002 14:17:30 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Hi Mark, > > > I've already said how to put them in the DNS. It requires a new > > record but it will work and it will remove the need for two faced > > DNS unless the sites *wants* to use two faced DNS to hide the > > records. > > I don't have enough DNS expertise to fully evaluate your idea, but it > looks like an interesting possibility to resolve several problems with > putting IPv6 site-local addresses in the DNS. > > Have you made this suggestion on any DNS-related groups, like dnsext, > perhaps? It would be interesting to see if other DNS folks think that > this makes sense. > > Margaret I've bounced the idea of other DNS folks in the past and they have been happy enough with it. It was more a problem of getting it heard here. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 19:20:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T3Kc29020929; Mon, 28 Oct 2002 19:20:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T3KckR020928; Mon, 28 Oct 2002 19:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T3KY29020921 for ; Mon, 28 Oct 2002 19:20:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T3KhbB008489 for ; Mon, 28 Oct 2002 19:20:44 -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 UAA15493 for ; Mon, 28 Oct 2002 20:20:38 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA24226; Mon, 28 Oct 2002 19:20:20 -0800 (PST) Message-Id: <5.1.0.14.2.20021028221944.07abad90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 22:21:47 -0500 To: Mark.Andrews@isc.org From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: Keith Moore , "Michel Py" , ipng@sunroof.eng.sun.com In-Reply-To: <200210290317.g9T3HUBM026165@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've bounced the idea of other DNS folks in the past and > they have been happy enough with it. It was more a problem > of getting it heard here. > > Mark Well, I've certainly heard it, and it looks much better, to me, than the "two-faced" DNS hack I've heard described in the past. I'd love to hear what the other DNS folks think, because maybe this would be a promising approach to address one of the serious problems with private addressing. If you decide to write it up in a draft and/or post it to the dnsext mailing list, please let me know so that I can follow the discussion. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 20:00:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T40829021175; Mon, 28 Oct 2002 20:00:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T408bu021174; Mon, 28 Oct 2002 20:00:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T40329021164 for ; Mon, 28 Oct 2002 20:00:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T40DbB013721 for ; Mon, 28 Oct 2002 20:00:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21531 for ; Mon, 28 Oct 2002 20:00:07 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9T3xx022786; Mon, 28 Oct 2002 22:59:59 -0500 (EST) Message-Id: <200210290359.g9T3xx022786@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 18:34:04 PST.") <2B81403386729140A3A899A8B39B046405E3CF@server2000> Date: Mon, 28 Oct 2002 22:59:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Physically write-protected config? Obviously you don't realize what you > just wrote. I know what I meant, which is that you need physical access to the device to enable it for writing. Sorry if it wasn't clear. > > it's not as if vanilla ciscos are going to be TSOed for use > > in transport class aircraft anyway. > > Exactly the same as saying that vanilla PCs are not going to be used for > Cisco gear. you're saying that the requirements for TSO for aircraft components and cisco's requirements for hardware are similar? not from the cisco hardware I've seen... Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 20:15:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4Fl29021282; Mon, 28 Oct 2002 20:15:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T4FlRq021281; Mon, 28 Oct 2002 20:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4Fh29021274 for ; Mon, 28 Oct 2002 20:15:43 -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 g9T4FrbB015928 for ; Mon, 28 Oct 2002 20:15:53 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12826 for ; Mon, 28 Oct 2002 21:15:47 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F123F5A6C; Mon, 28 Oct 2002 23:15:46 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Oct 2002 23:15:46 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 23:15:46 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9774@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+u1TSF7osR2irSi60hzqCGkwPYAARjz4A From: "Bound, Jim" To: , X-OriginalArrivalTime: 29 Oct 2002 04:15:46.0794 (UTC) FILETIME=[DB222CA0:01C27F01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T4Fi29021275 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, So if I read your view. Your saying. Control them but do not revoke them? The question is can we control them then right? But if we can't figure it out or agree then that could be revoke? I would hope we can control and not revoke. But as you know I don't believe they should have ever been permitted in the first place in IPv6. Site-Locals and 1918 are BOGUS that is not how to control what they wanted to do in the first place. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, October 28, 2002 2:47 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > I have a basic problem with this thread. We have a few people > discussing fundamental changes in close to a vacuum. At best > the result of this discussion should be a separate BCP, but > before that happens operators of networks that actually use > 1918 space need to be engaged to find out their requirements. > > The whole idea that SL should be revoked if a global is > available is bogus. It is certainly reasonable for the > manufacturer of light switches to only support SL/LL rather > than potentially multiple global prefixes. There is no reason > for those devices to interact across a scope boundary, so the > peer nodes that may also need global access MUST keep their > SL to interact in the limited scope. > > Tony > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 20:24:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4OQ29021361; Mon, 28 Oct 2002 20:24:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T4OPb7021360; Mon, 28 Oct 2002 20: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4OM29021353 for ; Mon, 28 Oct 2002 20:24:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T4OVbB017223 for ; Mon, 28 Oct 2002 20:24:31 -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 VAA07055 for ; Mon, 28 Oct 2002 21:24:25 -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 297D582F; Mon, 28 Oct 2002 23:24:25 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Oct 2002 23:24:24 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 23:24:24 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B636@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+vAvihjGiXUSUQamadnBiQA9pSQARgAvw From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Hesham Soliman (EAB)" , "Keith Moore" , , "Steven Blake" , X-OriginalArrivalTime: 29 Oct 2002 04:24:24.0908 (UTC) FILETIME=[0FF418C0:01C27F03] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T4OM29021354 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We should not have to touch addr arch if we just want to control SLs and not Revoke them. Just to leave addr arch ALONE I vote for "control" now even though I want revoke and think SLs are a curse to IPv6 in the future. Lets control it. We have to leave addr arch alone unless there is no other alternative. Margaret's paradigm presents us that alternative and I think it will work. There is no perfect world there will NEVER be a perfect protocol. I recall one Ipng directorate member when we sat there looking at all the proposals. One in particular kept saying which one has less "warts" (a very bright guy named Greg :--)). I have taken those comments to heart in all IETF work as much as be liberal (I really just hate that word :--)) in what you receive but conservative in what you send. IMO SLs are an IPv6 wart. Lets not cut off the hand where the wart is but rather kiss it and make it beautiful like in those children stories. The problem is the wart is so ugly no one wants to get close and best we can do is put bandaid on it for now. That is what Margarets proposal does and it appears to me there is consensus to move forward with that idea. At least my read of these far to many emails but necessary I guess. /jim /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, October 28, 2002 2:53 PM > To: Margaret Wasserman > Cc: Hesham Soliman (EAB); 'Keith Moore'; > 'sommerfeld@east.sun.com'; 'Steven Blake'; ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > On Mon, 28 Oct 2002, Margaret Wasserman wrote: > > >2.5.6 Local-Use IPv6 Unicast Addresses > > > > > > Routers must not forward any packets with site-local source or > > > destination addresses outside of the site. > > > > > >This conflicts with the "treat as globals" stance. > > > > Not really. If we define that site-local unicast addresses > can only > > be used on non-globally-connected sites, there won't be any site- > > border routers that need to worry about this restriction. > > > > But, that doesn't make the restriction false. Site-local addresses > > should never be forward outside of a site. > > And what about: > > Site-local addresses are designed to be used for > addressing inside of > a site without the need for a global prefix. Although a subnet ID > may be up to 54-bits long, it is expected that globally-connected > sites will use the same subnet IDs for site-local and global > prefixes. > > > I think if we want to go down the road discussed in this > thread, I believe > some (relatively minor) changes in addrarch could clarify many things. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 20:47:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4lh29021508; Mon, 28 Oct 2002 20:47:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T4lhwe021507; Mon, 28 Oct 2002 20:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4le29021500 for ; Mon, 28 Oct 2002 20:47: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 g9T4lYbB020265 for ; Mon, 28 Oct 2002 20:47:34 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20507 for ; Mon, 28 Oct 2002 21:47:28 -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 3C112872; Mon, 28 Oct 2002 23:47:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Oct 2002 23:47:28 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 23:47:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B637@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+xIE87zJvcurDS6WO5sre9B7WnAAP9sHw From: "Bound, Jim" To: "Dan Lanciani" , X-OriginalArrivalTime: 29 Oct 2002 04:47:28.0082 (UTC) FILETIME=[4863B320:01C27F06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T4le29021501 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, This is quite a good commentary. What you say is exactly what will happen too in the commercial deployment of IPv6 (as opposed to AD, research, and non fully supported product where the vendor states you can use this in your production network). But I have heard this TCP long lived connection discussion for a long time. Lets discuss. But first anyone who believes they have the right to keep telnet up 24 hours a day across global networks is sadly mistaken and that's just crazy and lets evil security bad people really get to test their skill out. I know of a user who has to have long lived TCP connections in mission critical situation and wants to do it with IPv6. I have advised them to NOT use SLs. Here is why. The user implementation will have user internal routers across the site (properly defined). But people in the site will and must have access out of the site and that is why we have that problem long discussed here in reality from a few users. That is critical for IPv6 to solve right now. Margaret's proposal solves that problem and will save lives IMO with IPv6. But TCP because we have sites and not multiple links connected using global addresses I don't believe provides any more guarantee or robustness for a long lived TCP connection on a site. Simply because the only reason it will break the site TCP is an error in the network administration, router going down (then we get into dual rail but lets not go there for now), or the cosmos sends a lighting bolt into the core router of the site. So SLs buy a site TCP long lived connections nothing I can see over global addresses. The only place that is not true is a link. And for that we do have link-local. So I still do not see the value of SLs even for long lived connections. The way to solve long lived connections and this is even more hairy than SLs and that is by dynamically reconfiguring the two nodes to use different addresses and vendor customized True High Availability for TCP and SCTP (I believe SCTP is better now just like IPv6 is better than IPv4 but needs more testing and trial networks). So I am not clear your argument of long lived connections is an argument for SLs? It is an argument for other work I believe to be important. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Dan Lanciani [mailto:ipng-incoming@danlan.com] > Sent: Monday, October 28, 2002 3:52 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > I think it's great the folks are starting to consider the > difficult problems associated with site-local addresses in > particular and scoped addresses in general. In the past > these have been glossed over with hand-waving arguments that > scopes would ``just work'' with minimal application > involvement and a little DNS magic. > > Before you try to solve the problems by effectively reducing > scopes to a degenerate case of one and restricting site-local > addresses to sites with no global addresses (or even with no > external connectivity), please keep in mind that site-local > addresses have been offered up as the solution to a number of > other problems which themselves were difficult to hand-wave > away. For example, the ability to have long-term tcp > connections within a site in the face of global address > renumbering has--given the lack of any protocol or > application support for that renumbering--been pushed onto > site-local addressing. (The problem is hardly confined to > tcp, but that's the usual example cited.) > > Any language that reduces site-local addresses to > second-class citizens (or, worse, implies that they should > not be used concurrent with global addresses) will give stack > and application vendors an excuse to fail to support such > configurations. I don't think you want to open such a huge > can of worms as it will entail revisiting every problem that > has been ``resolved'' with an admonition to simply use > site-local addresses. > > 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 Oct 28 20:51:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4pU29021545; Mon, 28 Oct 2002 20:51:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T4pUTd021544; Mon, 28 Oct 2002 20:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T4pR29021537 for ; Mon, 28 Oct 2002 20:51:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T4paMq017891 for ; Mon, 28 Oct 2002 20:51:36 -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 UAA22797 for ; Mon, 28 Oct 2002 20:51:31 -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 CF61D5852; Mon, 28 Oct 2002 23:51:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Oct 2002 23:51:30 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 23:51:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE977D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+xcw1H+1nDYnaRK+muTHkTEBarAAQJnFg From: "Bound, Jim" To: "Roy Brabson" , Cc: X-OriginalArrivalTime: 29 Oct 2002 04:51:30.0705 (UTC) FILETIME=[D9010810:01C27F06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T4pR29021538 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Roy, I agree with you but another point I really don't like. In the situation in same site per your statement below. A node could send to a dst addr with less scope in its src. If the packet goes far enough it can never return (kind of like charlie on the MTA in Boston). Another property of SL I don't like. But before we gave imnplementational and operational real thought to SLs and lumped them in IPv6 we had this same problem. With Link-Local. What is the point of sending to a global address with a Link-Local? That's unidirectional. Just another point of darkness about SLs. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Roy Brabson [mailto:rbrabson@us.ibm.com] > Sent: Monday, October 28, 2002 3:58 PM > To: alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > I have a basic problem with this thread. We have a few people > > discussing fundamental changes in close to a vacuum. At best the > > result of this discussion should be a separate BCP, but before that > > happens operators of networks that actually use 1918 space > need to be > > engaged to find out their requirements. > > > > The whole idea that SL should be revoked if a global is > available is > > bogus. It is certainly reasonable for the manufacturer of light > > switches to only support SL/LL rather than potentially > multiple global > > prefixes. There is no reason for those devices to interact across a > > scope boundary, so the peer nodes that may also need global access > > MUST keep their SL to interact in the limited scope. > > I thought global addresses could be used to communicate with > peers using > addresses of any scope as long as the interface over which > the packet is > sent is in the same scope zone as that peer. As such, a node with a > global address does not require a site-local address to > communicate with a > node which has a site-local address but lacks a global > address, as long as > the two nodes reside within the same site. > > 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 Oct 28 21:02:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T52Z29021647; Mon, 28 Oct 2002 21:02:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T52ZLi021646; Mon, 28 Oct 2002 21:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T52V29021639 for ; Mon, 28 Oct 2002 21:02:31 -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 g9T52fbB022487 for ; Mon, 28 Oct 2002 21:02:41 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12720 for ; Mon, 28 Oct 2002 21:02:35 -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 7B7B45A57; Tue, 29 Oct 2002 00:02:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 00:02: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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:02:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9780@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zXaPI6UEZGueRXqKtZjfN7LJ/QAOqJcg From: "Bound, Jim" To: "Margaret Wasserman" , "Dan Lanciani" Cc: X-OriginalArrivalTime: 29 Oct 2002 05:02:35.0346 (UTC) FILETIME=[65293320:01C27F08] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T52W29021640 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As one implementor. They create so many conditionals in the code because they are virtual to ship it means like major testing that does not exist today for networking. That is not a reason not to do anything. But if it is baked (I don't think it is yet) it is rather cumbersome to build a product with it that won't break. I mean a product that has a total warranty on it and means to the user "you can run this in a production operation and we will be responsible". Not an early adopter kit OK. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, October 28, 2002 4:56 PM > To: Dan Lanciani > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > > > >Any language that reduces site-local addresses to > second-class citizens > >(or, worse, implies that they should not be used concurrent > with global > >addresses) will give stack and application vendors an excuse > to fail to > >support such configurations. > > What do stack and application vendors need to do to support > site-local addressing? > > And what makes you think that they are doing those things now? > > The majority of stack and application implementations with > which I am familiar make no distinction at all between > site-local address and globals. > > This is appropriate if site-locals will be used only on > non-globally connected sites (so, effectively, site-local == global). > > Margaret > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 21:09:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T59L29021744; Mon, 28 Oct 2002 21:09:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T59Loh021743; Mon, 28 Oct 2002 21:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T59I29021736 for ; Mon, 28 Oct 2002 21:09:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T59SbB023367 for ; Mon, 28 Oct 2002 21:09:28 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20780; Mon, 28 Oct 2002 22:09:21 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9T595BM026467; Tue, 29 Oct 2002 16:09:05 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210290509.g9T595BM026467@drugs.dv.isc.org> To: Keith Moore Cc: Alain Durand , Michel Py , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Mon, 28 Oct 2002 20:02:05 CDT." <200210290102.g9T125022413@astro.cs.utk.edu> Date: Tue, 29 Oct 2002 16:09:05 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Except with SL you don't re-number. You just provide a additional > global address. All your nodes continue to use there existing SL > addresses. > > and your applications break when they talk to external nodes and they find > that using SLs for referrals no longer works. And application break when you use non-globally-routed GA's. People want permanent private address space be that multiply allocated (SL/1918) or non-globally-routed global address space (NGRGAS). Passing addresses in either is not guaranteed to work with every node. NGRGAS removes one address maps to multiple nodes but it does not help identify if two nodes share a common site though you can identify if a node shares your site. NGRGAS also requires a registry to allocate the address space. However if you look at my SA6 solution you can reliably detect if two nodes share a common site. You can pass around references without ambiguity. You don't need a seperate registry. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 21:12:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Cu29021791; Mon, 28 Oct 2002 21:12:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5CuJx021790; Mon, 28 Oct 2002 21:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Cr29021783 for ; Mon, 28 Oct 2002 21:12:53 -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 g9T5D2bB023813 for ; Mon, 28 Oct 2002 21:13:02 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28133 for ; Mon, 28 Oct 2002 22:12:56 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5D3482DF1; Tue, 29 Oct 2002 00:12:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 00:12:56 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:12:55 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9783@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAAAFHuAAA9BEbA= From: "Bound, Jim" To: "Michel Py" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 29 Oct 2002 05:12:56.0236 (UTC) FILETIME=[D73D7EC0:01C27F09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5Cr29021784 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, There is now debate if sensors should even have IP addresses and if IP is even needed. Clearly the Gateway sensors will need IP but then that should not be SL but global in the sense of global for the gateways communications. And most sensors are dealing with speeds across the plane of physics where IP stacks would be a bottleneck as we know them. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Monday, October 28, 2002 5:04 PM > To: Margaret Wasserman; alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Margaret Wasserman wrote: > > I've spent much of the last 7+ years working on IPv6 > > stacks for embedded systems, and they have all > > supported global addressing. > > The issue is not the capability of the devices to support > global addressing, but the desire of the network designer to > configure a set of devices that specifically don't have > access to the public address space. > > There are some military applications where devices have no > business talking to the outside world. Control devices or > sensors on a water distribution system or a power grid are > another good example. These devices have no business > whatsoever accessing the public internet, and it might be a > requirement that the devices themselves have support for > public addresses removed. > > 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 Mon Oct 28 21:18:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Ik29021872; Mon, 28 Oct 2002 21:18:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5Ijiq021871; Mon, 28 Oct 2002 21:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Ig29021864 for ; Mon, 28 Oct 2002 21:18:42 -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 g9T5IqMq021264 for ; Mon, 28 Oct 2002 21:18:52 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18483 for ; Mon, 28 Oct 2002 21:18:46 -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 42C6B5A00; Tue, 29 Oct 2002 00:18:46 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 00:18:46 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:18:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9785@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAABO/TgAA5GlaA= From: "Bound, Jim" To: "Michel Py" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 29 Oct 2002 05:18:46.0058 (UTC) FILETIME=[A7C018A0:01C27F0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5Ih29021865 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, There is not reason at all why what you stated could not be link-local addresses. I would argue if sensors do what I hear they will do link-locals are fine and we do have controls on that and they are not forwarded off the link. The cockpit and intra-connections could be viewed as on link easily. Access to the FAA or GPA Sat-Com would require global (hmm maybe inter-planetary scope :--)) and as in my previous mail those would be gateways to the sensors. You may give good argument to not kill them yet but not sure against what Margaret proposed. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Monday, October 28, 2002 5:46 PM > To: Margaret Wasserman; alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > Margaret, > > > What would a light switch do differently to support site-local as > > opposed to global? It still needs to get a prefix from a > router and > > combine it with an IID using address autoconf. So, I don't > understand > > what system requirements could be eliminated by refusing > > to support global prefixes. > > There is a matter of _implementing_ system requirements, not > eliminating them. > > Let's talk about an airplane's IPv6 internal systems. There > will be a requirement that the rudder's embedded controller > reacts to site-local only, just in case a bozo mixes up > something. OTOH, the NAV computer does need to talk to the > outside word to extract weather or other in-flight dynamic > data and to report to ground. > > All that stuff is displayed simultaneously on the glass > cockpit CRTs, so at some point there is one computer in the > plane that has access simultaneously to external data and to > internal data. > > Now, explain me how you design that network (the plane) with > deprecating site-locals when global addresses are present. > Modern plane designs are multiple redundant networks that > carry data for almost all of the plane's devices. > > 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 Mon Oct 28 21:26:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Q729021971; Mon, 28 Oct 2002 21:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5Q6Yr021970; Mon, 28 Oct 2002 21:26:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Q329021960 for ; Mon, 28 Oct 2002 21:26:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T5QCMq022198 for ; Mon, 28 Oct 2002 21:26:12 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26507 for ; Mon, 28 Oct 2002 22:26:07 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 810F340E7; Tue, 29 Oct 2002 00:26:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 00:26:06 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:26:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B638@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+0illfnT9ow+FQqeOlQvdIqoGUwAAVcRAAA3Re2A= From: "Bound, Jim" To: "Michel Py" , "Alain Durand" Cc: X-OriginalArrivalTime: 29 Oct 2002 05:26:06.0381 (UTC) FILETIME=[AE340DD0:01C27F0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5Q329021961 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, All know now that NAT breaks security and destroys end-2-end. In the other part of my life and it sounds like we talk to similar people, I am struggling now with the other transtion and that is from NAT. But its not like people like it :---). Its kind of like your kid is on drugs. You still love the kid but it would be nice if you could get them off drugs. NAT hides stuff clearly and stuff that also does bad things to the network as a note and one of its uses I find lately, but its not a plan to move forward. And we will need to provide that security with IPv6 as a note that they did not get with NAT. So this entire private address/NAT illusion put down on folks now will affect us still but we can fix it now with strong security for IPv6 and doing what Margaret suggested and Tony has suggested and we can leave it in the architecture for now till a later day. I think we are all in violent agreement here? Leave the architecture alone for tomorrow. Use Margarets fix as BCP or whatever. Michel and I can use it in physics experiments tomorrow. And we can work on the next important topic for v6ops? And what Dan wanted too I think that is another task but probably not here. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Monday, October 28, 2002 5:46 PM > To: Alain Durand > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Alain Durand wrote: > > Oh... the old argument that NAT/private address > > brings security... > > Go tell that to people that write requirements, especially > the ones that work for the government, and when you have > convinced them get back to us, ok? > > 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 Mon Oct 28 21:35:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Zg29022164; Mon, 28 Oct 2002 21:35:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5Zg1c022163; Mon, 28 Oct 2002 21:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5Zc29022154 for ; Mon, 28 Oct 2002 21:35:38 -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 g9T5ZmbB027112 for ; Mon, 28 Oct 2002 21:35:48 -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 VAA07816 for ; Mon, 28 Oct 2002 21:35:42 -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 28D3E916; Tue, 29 Oct 2002 00:35:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 00:35:42 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:35:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9788@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+4XD/EZO+Jn63Q6+5XDpJsgNLlAAK0chw From: "Bound, Jim" To: , "Keith Moore" Cc: "Michel Py" , "Margaret Wasserman" , X-OriginalArrivalTime: 29 Oct 2002 05:35:42.0049 (UTC) FILETIME=[05540510:01C27F0D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5Zd29022157 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, Because we could not clearly define sin6_scope_ID its basically a void in the base API now. And IEEE did the same thing. Works for link-locals yes. So if your DNS 2-face reqs that it won't work yet because of lack of consensus on scoping and no one has implemented a product for production networks today that use SLs. I asked Richard to speak up but until I hear from him I will assume that. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Mark.Andrews@isc.org [mailto:Mark.Andrews@isc.org] > Sent: Monday, October 28, 2002 7:20 PM > To: Keith Moore > Cc: Michel Py; Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > > > In a nutshell, the point you are trying to make is that RFC1918 > > > addresses are bad because NAT exists. > > > > no, that's missing the point. use of RFC 1918 addresses in > a network > > that can also use global Internet addresses is harmful > regardless of > > whether that connection to the global Internet uses NAT or > whether it > > is merely via a router that filters traffic to/from the 1918 > > addresses. > > > > NAT is irrelevant to this particular problem. The problem is that > > in the presence of either 1918 or SLs applications have to > deal with > > a mixture of scoped and global addresses without any good > way of knowing > > whether such an address is valid (and whether it means the > same thing) > > in the context of a particular node. > > Which just means that we need to provide a way for the > application / > library to return appropriate addresses. Make SL work > rather than > saying "kill them" or "don't put them in the DNS". > > I've already said how to put them in the DNS. It requires a new > record but it will work and it will remove the need for > two faced > DNS unless the sites *wants* to use two faced DNS to > hide the records. > > Site locals provide a solution for a certian problem > space. They > do create additional problems but they are not > insolvable problems > and are no different to the problems causes by LLs. > > You need a function that looks up names and returns > addresses along > with the scope_id. We have that in getaddrinfo(). You need a > function that takes a address and a scope_id and > returns the name. > We don't have that but it is very easy to do that in > the DNS if you > want to privided you have a scope-id to scope-name > function which > is need. > > e.g. > . PTR > > It's not zero-conf but sites will most probably never > be zero-conf. > > e.g. > > foo.example.net. SA6 1080:0:0:0:8:800:200C:417A . > foo.example.net. SA6 FE80:0:0:0:8:800:200C:417A > my-site.example.net. foo.example.net. SA6 > FEC0:0:0:0:8:800:200C:417A my-link.example.net. > c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0. > 1.ip6.arpa. ( > PTR foo.example.net. ) > c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E. > F.my-site.example.net. ( > PTR foo.example.net. ) > c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E. > F.my-link.example.net. ( > PTR foo.example.net. ) > > and you have a local table that maps > my-site.example.net and my-link.example.net to > appropiate scope-id > values. > > Now if you want to send address between applications in > binary format > just send SA6 rdata instead of AAAA rdata. > > Applications / libraries can filter out the addresses that are > not useful to them if they want. > > Mark > > > > 2. site-local is bad because RFC1918 is bad. > > > > sorry - the two are quite similar, and they cause similar > problems for > > apps. > > > > > >> and a global address. > > > > > > > please, elaborate. I haven't seen a good one yet. > > > > > > A somehow isolated subnet, where most hosts would have site-local > > > only addresses, except for a gateway or proxy that would > have both. > > > > that's what 1918 was intended for. again, I don't have a > huge problem > > with it as long as the apps don't have to deal with > multiple scopes - > > but experience with 1918 predicts that that's exactly what will > > happen. > > > > > > you're missing the burden that having a mixture of SLs > and globals > > > > puts on apps. > > > > > > You are missing the point, IMHO. This is not your call nor mine. > > > Site-local addresses do exist, been there for long, some > people will > > > purposedly choose to use them in combination with global > addresses. > > > As of today, the address selection draft addresses use of > site-local > > > and global addresses simultaneously and I do not see a reason to > > > change it. > > > > IETF's job is to try to explain what will make the network > work well. > > Imposing constraints on the use of SLs will help the > network work better. > > If SLs are encouraged as in the current draft it will > degrade the ability > > of the network to support applications. > > > > Keith > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 21:38:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5cN29022241; Mon, 28 Oct 2002 21:38:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5cNSv022240; Mon, 28 Oct 2002 21:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5cK29022233 for ; Mon, 28 Oct 2002 21:38:20 -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 g9T5cTMq023879 for ; Mon, 28 Oct 2002 21:38:29 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25673 for ; Mon, 28 Oct 2002 21:38:24 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C5B6B18E8 for ; Tue, 29 Oct 2002 00:38:20 -0500 (EST) Date: Tue, 29 Oct 2002 00:38:20 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021028221944.07abad90@mail.windriver.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021029053820.C5B6B18E8@thrintun.hactrn.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5cK29022234 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Mon, 28 Oct 2002 22:21:47 -0500, Margaret Wasserman wrote: > > Well, I've certainly heard it, and it looks much better, to me, > than the "two-faced" DNS hack I've heard described in the past. > > I'd love to hear what the other DNS folks think, because maybe > this would be a promising approach to address one of the serious > problems with private addressing. >From a strictly DNS technical point of view, Mark's proposal is fine. That is, the DNS protocol mechanics are not a problem (nor would I expect them to be, coming from Mark). There is, however, the issue of the local mapping table between scope id and DNS equivilent (my-site.example.net and my-link.example.net in Mark's example). As Mark mentioned, this is not zeroconf. Also note that this mechanism uses a new RR type. This is certainly doable, but it's a bit painful for address types due to the DNS additional section processing rules and the number of other pieces of deployed code that would need to be updated. Of course, one could back translate SA6 to AAAA, but that breaks end-to-end DNSSEC.... Dunno if this is starting to sound familiar to anybody else, but my ears are still ringing from the AAAA vs A6 debate, and I don't particularly want to relive that experience anytime soon. The above comments are only intended to discuss the DNS sub-thread, and should not be construed as a change from my previously stated support for Margaret's proposal to forbid use of site-local addresses on globally-connected networks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 21:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5hn29022390; Mon, 28 Oct 2002 21:43:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5hnsu022389; Mon, 28 Oct 2002 21:43:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5hj29022370 for ; Mon, 28 Oct 2002 21:43:45 -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 g9T5hdMq024555 for ; Mon, 28 Oct 2002 21:43:39 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13116 for ; Mon, 28 Oct 2002 22:43:33 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B529D5968; Tue, 29 Oct 2002 00:43: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); Tue, 29 Oct 2002 00:43: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="us-ascii" Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 00:43:31 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9789@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+48oWcIWJSE72QAKTCTZB1EYGygAAB9wQAApXDbA= From: "Bound, Jim" To: "Michel Py" , "Keith Moore" Cc: "Margaret Wasserman" , , X-OriginalArrivalTime: 29 Oct 2002 05:43:32.0508 (UTC) FILETIME=[1DBE5DC0:01C27F0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5hj29022377 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, OK lets try to cut to the chase as they say. Clearly in a mission critical environment where lets say people are dead (I mean really dead) because the network screws up. It is wise to reduce the single points of failure. But that should not be done as Keith stated with separate address space and I will add it can be done with global address space. Any packet can prevented from leaving any network or one coming in with absolute certainity. There is no plug into the network. That is what most mission critical systems do. Now to evolve those systems to use data outside which is where they are going IMO. That does not mean we require SLs. What it means is we need par excellence security. I would rather spend my time working on that par excellence security than using duct tape and band-aids to patch SLs together. But to argue philosophically that the conclusion to these mission critical environments requires a separate address space as a premise is simply a false premise. The only reason 1918 was valid was because: 1. We did not have IP security in the works even as we do now. 2. We were paranoid about v4 address space with 2-to-the-32. And then we got NAT. Lets not do this with Ipv6. /jim /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Monday, October 28, 2002 7:45 PM > To: Keith Moore > Cc: Margaret Wasserman; alh-ietf@tndh.net; ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > >> Michel Py wrote: > >> Let's talk about an airplane's IPv6 internal systems. > There will be a > >> requirement that the rudder's embedded controller reacts to > >> site-local only, just in case a bozo mixes up something. OTOH, the > >> NAV computer does need to talk to the outside word to > extract weather > >> or other in-flight dynamic data and to report to ground. > > > Keith Moore wrote: > > that's what packet filtering is for. > > Keith, you don't get my point. The requirement for site-local > is because someone or something can mess up packet filtering. > It is in *addition* of the packet filtering. In an airplane, > one level of security does not take off. > > 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 Mon Oct 28 21:59:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5xR29022692; Mon, 28 Oct 2002 21:59:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T5xRag022691; Mon, 28 Oct 2002 21:59:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T5xO29022684 for ; Mon, 28 Oct 2002 21:59: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 g9T5xXMq026793 for ; Mon, 28 Oct 2002 21:59:33 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18859 for ; Mon, 28 Oct 2002 22:59:28 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 21:59:18 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 21:59:19 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 21:59:23 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 21:59:22 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+1WjmWQcd7ON3Q6qsae40OnvTZQAOSWjg From: "Brian Zill" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 29 Oct 2002 05:59:23.0474 (UTC) FILETIME=[54904320:01C27F10] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T5xO29022685 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman writes: > > Private addressing does not provide any time of security that > cannot be obtained (and more easily, in most cases) by > appropriate configuration of firewalls or filters on routers. So are you advocating that people use global addresses with a firewall and/or filters to block outside connectivity for part of their address space? Doesn't that just create a weird form of private address space? And worse (since it is not officially sanctioned) one that applications can't recognize? One advantage of having scoped addresses defined in the IPv6 architecture from the start is that applications can know not to pass them outside of their scope. If we instead suggest that people firewall/filter off random portions of the global address space, then apps will blindly pass those addresses around in the data stream, mistakenly thinking that they are real global addresses. Only having dedicated scoped address space allows apps to do the right thing. --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 Oct 28 22:16:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6GE29022829; Mon, 28 Oct 2002 22:16:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6GEuJ022828; Mon, 28 Oct 2002 22:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6GB29022821 for ; Mon, 28 Oct 2002 22:16:11 -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 g9T6GKMq028706 for ; Mon, 28 Oct 2002 22:16:20 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24853 for ; Mon, 28 Oct 2002 23:16:14 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 22:16:12 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 22:16:11 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 22:16:12 -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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 22:16:11 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+xcw1H+1nDYnaRK+muTHkTEBarAAQJnFgAAKtdpA= From: "Brian Zill" To: "Bound, Jim" Cc: X-OriginalArrivalTime: 29 Oct 2002 06:16:12.0102 (UTC) FILETIME=[ADC0AE60:01C27F12] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T6GB29022822 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jim Bound writes: > > A node could send to a dst addr with less scope in its src. > If the packet goes far enough it can never return. The packet will hit a router which will refuse to forward it. This is exactly the same as a node sending a packet with inadequate hop count to reach the destination. In both cases the sending node gets back an ICMP error message (scope exceeded or hop count exceeded). There is nothing strange here. --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 Oct 28 22:16:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6Gw29022846; Mon, 28 Oct 2002 22:16:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6GvMU022845; Mon, 28 Oct 2002 22:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6Gs29022838 for ; Mon, 28 Oct 2002 22:16: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 g9T6H3bB002722 for ; Mon, 28 Oct 2002 22:17:03 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23311 for ; Mon, 28 Oct 2002 23:16:57 -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 17854AA0; Tue, 29 Oct 2002 01:16:57 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 01:16:56 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 01:16:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B639@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+1WjmWQcd7ON3Q6qsae40OnvTZQAOSWjgAADb19A= From: "Bound, Jim" To: "Brian Zill" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 29 Oct 2002 06:16:56.0920 (UTC) FILETIME=[C8775D80:01C27F12] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T6Gs29022839 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, The argument that globals don't benefit firewalls is not true. In Digital we ran globals company wide and now in HP. The Firewall is there for sure. But the algorithms are to check security parameters coming in and other filtering rules the translation and mappings and data structure lookups and the duplicate data paths are not needed. In addition with Ipsec it will make the firewalls even faster because now all the many filters are not needed because the SA between two nodes or an extranet router can do Ipsec verification. So the technical ability of globals to pass through firewalls is far better and I believe an order of magnitude not just basic perf gain. In addition philosophically private addresses are simply not wise. But won't go there yet again. But IPv6 does not need SLs today at all and they definitely should not put large mission critical operations at risk with IPv6 at all. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Brian Zill [mailto:bzill@microsoft.com] > Sent: Tuesday, October 29, 2002 12:59 AM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Margaret Wasserman writes: > > > > Private addressing does not provide any time of security that > > cannot be obtained (and more easily, in most cases) by > > appropriate configuration of firewalls or filters on routers. > > So are you advocating that people use global addresses with a > firewall and/or filters to block outside connectivity for > part of their address space? Doesn't that just create a > weird form of private address space? And worse (since it is > not officially sanctioned) one that applications can't recognize? > > One advantage of having scoped addresses defined in the IPv6 > architecture from the start is that applications can know not > to pass them outside of their scope. If we instead suggest > that people firewall/filter off random portions of the global > address space, then apps will blindly pass those addresses > around in the data stream, mistakenly thinking that they are > real global addresses. Only having dedicated scoped address > space allows apps to do the right thing. > > --Brian > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 22:21:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6Le29022926; Mon, 28 Oct 2002 22:21:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6LekF022925; Mon, 28 Oct 2002 22:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6Lb29022918 for ; Mon, 28 Oct 2002 22:21: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 g9T6LkMq029531 for ; Mon, 28 Oct 2002 22:21:46 -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 WAA23047 for ; Mon, 28 Oct 2002 22:21:42 -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 09D2D5940 for ; Tue, 29 Oct 2002 01:21:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 01:21:41 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 01:21:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B63A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+xcw1H+1nDYnaRK+muTHkTEBarAAQJnFgAAKtdpAAAHUEYA== From: "Bound, Jim" To: "Brian Zill" Cc: X-OriginalArrivalTime: 29 Oct 2002 06:21:41.0877 (UTC) FILETIME=[72505A50:01C27F13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T6Lb29022919 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ICMP messages are for a purpose if we remove SLs they will be used as today which we understand to manage and operate networks. That is not the case for SLs. Your arguing that apples and oranges are the same logically and they are not and have completely different properties. In fact SLs have other properties that cause network failures too. Too many quite frankly. And many of us have known this for years. Maybe now that it is being discussed in an operational WG we can put some controls on them till we better understand them. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Brian Zill [mailto:bzill@microsoft.com] > Sent: Tuesday, October 29, 2002 1:16 AM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Jim Bound writes: > > > > A node could send to a dst addr with less scope in its src. If the > > packet goes far enough it can never return. > > The packet will hit a router which will refuse to forward it. > This is exactly the same as a node sending a packet with > inadequate hop count to reach the destination. In both cases > the sending node gets back an ICMP error message (scope > exceeded or hop count exceeded). There is nothing strange here. > > --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 Oct 28 22:36:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6aA29023150; Mon, 28 Oct 2002 22:36:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6a9nY023149; Mon, 28 Oct 2002 22:36:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6a629023142 for ; Mon, 28 Oct 2002 22:36:06 -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 g9T6aGMq001309 for ; Mon, 28 Oct 2002 22:36:16 -0800 (PST) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA00299 for ; Mon, 28 Oct 2002 23:36:09 -0700 (MST) Message-ID: <00b801c27f15$738bae90$5c28010a@feroz> From: "Mohammad Feroz" To: Subject: IGMP in IPv6 ? Date: Tue, 29 Oct 2002 12:06:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01C27F43.8D013C40" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01C27F43.8D013C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, What is the equivalent of IPv4 IGMP protocol(v1/v2) in IPv6? Want to = know the protocol used for joining or leaving the multicast group in = IPv6. Thanks & Best Regards, - Feroz ********************************************************* Mohammed Feroz, Networking & Communication Group, Design & Development Centre, TATA Elxsi Limited, Bangalore Phone: +91-80-8410222=20 Fax: +91-80-8410219 ********************************************************* ------=_NextPart_000_00B5_01C27F43.8D013C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
What is the equivalent of IPv4 IGMP = protocol(v1/v2)=20 in IPv6? Want to know the protocol used for joining or leaving the = multicast=20 group in IPv6.
 
Thanks & Best Regards,
-=20 Feroz
 
*********************************************************=
Mohammed=20 Feroz,
Networking & Communication Group,
Design & = Development=20 Centre,
TATA Elxsi Limited, Bangalore
Phone: +91-80-8410222 =
Fax:=20 +91-80-8410219
*******************************************************= **
------=_NextPart_000_00B5_01C27F43.8D013C40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 22:42:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6gW29023210; Mon, 28 Oct 2002 22:42:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6gWBO023209; Mon, 28 Oct 2002 22:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6gT29023202 for ; Mon, 28 Oct 2002 22:42:29 -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 g9T6gdbB005790 for ; Mon, 28 Oct 2002 22:42:39 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17579 for ; Mon, 28 Oct 2002 22:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id g9T6gWGR020053; Tue, 29 Oct 2002 15:42:32 +0900 Date: Tue, 29 Oct 2002 15:42:31 +0900 (JST) Message-Id: <20021029.154231.126658699.yoshfuji@linux-ipv6.org> To: feroz@tataelxsi.co.in Cc: ipng@sunroof.eng.sun.com Subject: Re: IGMP in IPv6 ? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <00b801c27f15$738bae90$5c28010a@feroz> References: <00b801c27f15$738bae90$5c28010a@feroz> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <00b801c27f15$738bae90$5c28010a@feroz> (at Tue, 29 Oct 2002 12:06:02 +0530), "Mohammad Feroz" says: > What is the equivalent of IPv4 IGMP protocol(v1/v2) in IPv6? Want to know the protocol used for joining or leaving the multicast group in IPv6. MLD (Multicast Listener Discovery), RFC 2710. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 22:51:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6pQ29023349; Mon, 28 Oct 2002 22:51:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T6pQBg023347; Mon, 28 Oct 2002 22:51:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T6pM29023340 for ; Mon, 28 Oct 2002 22:51:22 -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 g9T6pWMq003070 for ; Mon, 28 Oct 2002 22:51:32 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02619 for ; Mon, 28 Oct 2002 22:51:26 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9T6pDc10451; Tue, 29 Oct 2002 08:51:13 +0200 Date: Tue, 29 Oct 2002 08:51:12 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: Michel Py , Keith Moore , , Subject: Choices to go forward with SL [RE: Limiting the Use of Site-Local] In-Reply-To: <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Oct 2002, Margaret Wasserman wrote: > In my opinion, there are three possible choices here: There are two others: (0) Limit the scope of the IPv6 WG's problem, by forbidding the use of site-local addresses on globally-connected networks in the scoped addressing architecture and clarifying it in the revised addrarch document. This would not preclude work in this area by other groups within the IETF/IRTF, and we could remove the restriction when the implications are fully understood. > (1) Limit the scope of the IPv6 WG's problem, by > forbidding the use of site-local addresses > on globally-connected networks in the > scoped addressing architecture. This would > not preclude work in this area by other > groups within the IETF/IRTF, and we could > remove the restriction when the implications > are fully understood. > > (2) Develop a complete solution for scoped unicast > addressing within the IPv6 WG. This would > include solving the problems they cause for > all protocols/layers. > > (3) Define an IP-level solution for scoped addressing > (similar to what is currently in the scoped > addressing architecture), and consider all > of the implications of that architecture on > other protocols/layers to be someone else's > problem. (4) As 0) and 1) but kill all references to SL in addrarch-v3 > The first choice is both responsible and doable. But it gives a totally wrong picture to a reader reading a revised edition of addrarch. So it's unclear. 0) is clear, responsible and doable. 4) is too rash action for now, I believe. > I have deep concerns about the second choice, along two lines: > (1) I think it is important that we stabilize and complete IPv6 > quickly, as folks are widely implementing and deploying it, and > (2) I don't know that we have the expertise (in the IPv6 WG or > anywhere in the IETF, without further research) to solve these > problems. > > And, in my opinion, the third choice (which is what we seem to > be doing so far) is blatantly irresponsible. > > Are there people who want to argue for choices #2 and/or #3? > Or are there other choices that I've left out? Yes. I strongly urge for 0). Some wording changes are required in 2.5.6 second-last paragraph, and we may need to kill the last paragraph. I'm not even sure if we could get addrarch to draft standard, have folks implemented these two: --8<-- Routers must not forward any packets with site-local source or destination addresses outside of the site. --8<-- None of the implementations I use certainly haven't, and this has been around for a time now, even since RFC1884.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 28 23:00:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T70H29023460; Mon, 28 Oct 2002 23:00:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T70Hsw023459; Mon, 28 Oct 2002 23:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T70D29023450 for ; Mon, 28 Oct 2002 23:00:13 -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 g9T70NMq004037 for ; Mon, 28 Oct 2002 23:00:23 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11091 for ; Tue, 29 Oct 2002 00:00:10 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 23:00:04 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 23:00:04 -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); Mon, 28 Oct 2002 23:00:04 -0800 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: Limiting the Use of Site-Local Date: Mon, 28 Oct 2002 23:00:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+56l1fiOve5IoSjKkqCbA7aIvkQAKkRUw From: "Richard Draves" To: X-OriginalArrivalTime: 29 Oct 2002 07:00:04.0192 (UTC) FILETIME=[CE99BE00:01C27F18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T70E29023453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gee whiz, I really can not keep up with this thread. Why did I call it "craziness"? First, because it's not productive to revisit old design decisions. Scoped addresses and the notion that nodes would have multiple addresses of different scopes are design decisions from many years ago. Second, scoped addresses are an important part of the IPv6 architecture because they reflect today's internet architecture. The internet is no longer a fully-connected network of nodes with static addresses. (I get the impression that some participants in this thread would like to turn the clock back 20 years!) The world is more complicated now. Sites have strong boundaries; firewalls and two-faced DNS are commonplace for enterprise networks. Addresses occasionally change. The idea of restricting site-locals to completely disconnected networks doesn't make much sense to me. It's like saying you can have them but not really. How would we handle intermittently connected sites, or partially connected sites? What would happen when a network that is using site-locals gains global connectivity? This seems like a recipe for encouraging v6 NAT, which is not something we want. In my opinion, IPv6's explicit architectural support for multiple addresses and scoped addresses are two of its advantages over IPv4. Because they're baked in from the start, applications can do the right thing with scoped addresses. And one way or another they will be there eventually (look at how scoped addresses have crept into IPv4), so it's better if applications that need to know about them are coded that way from the start. In addition to the main architectural point above, there are some specific advantages of site-local addresses that others have mentioned, but let me put my own spin on them: 1. Site renumbering. Preserving long-lived connections across renumbering is not so compelling - I think most renumbering events can be planned for a large enough time-scale. More interesting is that various random static configurations that use site-locals do not have to be tracked down and updated. 2. Auto firewall. The site boundary is automatically a firewall for the site-local prefix. This is a simple model, easy for administrators to understand and easy for applications to recognize and cope with. Yes you can also put up filters for global prefixes, but that's more error-prone. (Let me throw out an idea that just occurred to me - some simple defaults in router configuration could help prevent errors in site boundary configuration. For example if the router is configured to run BGP, then by default it could assume its interfaces are in separate sites.) There's the question of how much burden do scoped addresses create for applications. For most applications, even on multi-sited hosts, there's no burden at all if they are coded using sockaddrs. Distributed applications that send around addresses do have to cognizant of scoped addresses. However this is not hard to deal with. For example I checked on how one such distributed application that is being built at MS handles this issue. The application looks at the scope of the correspondent and sends its addresses of matching scope. In other words, when talking to a global address you send your global addresses and when talking to a site-local address you send your site-local addresses. There's the question of implementation effort for the network stack to support scoped addresses. This is hard to quantify but I would say it was small. (And necessary regardless of site-locals, unless link-locals are next up for revisionist architecture.) The additional code in source & destination address selection was about 10 lines each. The additional code in route lookup and destination cache management was worse, maybe 100 lines. A scope-id needs to be passed around as an argument to various functions so there was a very small impact in many other places. 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 Mon Oct 28 23:01:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T71P29023487; Mon, 28 Oct 2002 23:01:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T71PWO023486; Mon, 28 Oct 2002 23:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T71L29023479 for ; Mon, 28 Oct 2002 23:01:22 -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 g9T71VbB008061 for ; Mon, 28 Oct 2002 23:01:31 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11725 for ; Tue, 29 Oct 2002 00:01:23 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 23:01:19 -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); Mon, 28 Oct 2002 23:01:19 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 23:01:25 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 23:01:18 -0800 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: Choices to go forward with SL [RE: Limiting the Use of Site-Local] Date: Mon, 28 Oct 2002 23:01:17 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choices to go forward with SL [RE: Limiting the Use of Site-Local] Thread-Index: AcJ/F/x/iSDLu1i0R0yp+WDPMkyD1gAAOXBA From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 29 Oct 2002 07:01:18.0615 (UTC) FILETIME=[FAF5CA70:01C27F18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T71M29023480 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not even sure if we could get addrarch to draft standard, > have folks > implemented these two: > > --8<-- > Routers must not forward any packets with site-local source or > destination addresses outside of the site. > --8<-- Yes, I implemented that. 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 Mon Oct 28 23:03:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T73D29023540; Mon, 28 Oct 2002 23:03:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T73ChT023539; Mon, 28 Oct 2002 23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T73929023532 for ; Mon, 28 Oct 2002 23:03:09 -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 g9T73IbB008531 for ; Mon, 28 Oct 2002 23:03:18 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12491 for ; Tue, 29 Oct 2002 00:03:13 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 28 Oct 2002 23:03:12 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Oct 2002 23:03:15 -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); Mon, 28 Oct 2002 23:03:11 -0800 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: Node Requirements Issues 4, 5, & 6 Date: Mon, 28 Oct 2002 23:03:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issues 4, 5, & 6 Thread-Index: AcJ6IhreNdu/OmqCSLa8Pm8/ua+L8QAIprWwANt2m3AAWZ4PwA== From: "Richard Draves" To: Cc: X-OriginalArrivalTime: 29 Oct 2002 07:03:11.0971 (UTC) FILETIME=[3E868B30:01C27F19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9T73929023533 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have gotten a number of private mails saying that Default > Address Selection should not be mandatory. What is the list's view? Of course I think it should be mandatory. Support for multiple addresses is one of IPv6's great features but there has to be some standardization to prevent it from being an unpredictable mess. Default Address Selection is definitely needed. 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 Mon Oct 28 23:38:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T7cd29024134; Mon, 28 Oct 2002 23:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T7cdga024133; Mon, 28 Oct 2002 23:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T7cY29024126 for ; Mon, 28 Oct 2002 23:38:34 -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 g9T7chMq009095 for ; Mon, 28 Oct 2002 23:38:43 -0800 (PST) Received: from starfruit.itojun.org (dhcp1252.nanog26.merit.net [192.35.165.252]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19509 for ; Mon, 28 Oct 2002 23:38:38 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 3E0DF7B9; Tue, 29 Oct 2002 16:37:54 +0900 (JST) To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Mon, 28 Oct 2002 23:00:03 PST. 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: Limiting the Use of Site-Local From: Jun-ichiro itojun Hagino Date: Tue, 29 Oct 2002 16:37:54 +0900 Message-Id: <20021029073754.3E0DF7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There's the question of how much burden do scoped addresses create for >applications. For most applications, even on multi-sited hosts, there's >no burden at all if they are coded using sockaddrs. Distributed >applications that send around addresses do have to cognizant of scoped >addresses. However this is not hard to deal with. For example I checked >on how one such distributed application that is being built at MS >handles this issue. The application looks at the scope of the >correspondent and sends its addresses of matching scope. In other words, >when talking to a global address you send your global addresses and when >talking to a site-local address you send your site-local addresses. application on multi-sited host is difficult, as - not every protocols are friendly with scoped addresses (scope identifier get stripped off during transit) - even if you successfully pass around scoped addresses with scope identifiers, scope identifiers (view of scope) differ by node. >There's the question of implementation effort for the network stack to >support scoped addresses. This is hard to quantify but I would say it >was small. (And necessary regardless of site-locals, unless link-locals >are next up for revisionist architecture.) The additional code in source >& destination address selection was about 10 lines each. The additional >code in route lookup and destination cache management was worse, maybe >100 lines. A scope-id needs to be passed around as an argument to >various functions so there was a very small impact in many other places. i would comment that it is very hard to get multi-sited router implementation right (specifically routing protocols). see descriptions by NEC guys a couple of months ago - it is a big mess. so my take is as follows: - we should at least forbid nodes from joining multiple sites. it will simplify things a lot. - we should document behavior of site-border routers, every gory details. this is the bottom line. i'm still a bit concerned about the use of scoped address in general, as it will cause confusion when scoped address leaks out of site in application payload (like email foo@bar@baz notation or whatever). but i feel it too late to kill it. 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 Tue Oct 29 00:33:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T8Xa29024972; Tue, 29 Oct 2002 00:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T8XaU5024971; Tue, 29 Oct 2002 00:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T8XV29024964 for ; Tue, 29 Oct 2002 00:33:31 -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 g9T8XebB021548 for ; Tue, 29 Oct 2002 00:33:40 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00613 for ; Tue, 29 Oct 2002 01:33:34 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:48cb:94e2:df65:e772]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9T8XEG72127; Tue, 29 Oct 2002 17:33:14 +0900 (JST) Date: Tue, 29 Oct 2002 17:34:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Margaret Wasserman , Michel Py , Keith Moore , , Subject: Re: Choices to go forward with SL [RE: Limiting the Use of Site-Local] In-Reply-To: References: <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.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: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Note: this message is not directly related to the main point of this thread.) >>>>> On Tue, 29 Oct 2002 08:51:12 +0200 (EET), >>>>> Pekka Savola said: > I'm not even sure if we could get addrarch to draft standard, have folks > implemented these two: > --8<-- > Routers must not forward any packets with site-local source or > destination addresses outside of the site. > --8<-- > None of the implementations I use certainly haven't, and this has been > around for a time now, even since RFC1884.. KAME can do this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 03:21:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TBLg29025537; Tue, 29 Oct 2002 03:21:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TBLgpF025536; Tue, 29 Oct 2002 03:21:42 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TBLc29025529 for ; Tue, 29 Oct 2002 03:21:38 -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 g9TBLlMq012788 for ; Tue, 29 Oct 2002 03:21:47 -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 DAA04524 for ; Tue, 29 Oct 2002 03:21:39 -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 GAA28113; Tue, 29 Oct 2002 06:19:15 -0500 (EST) Message-Id: <200210291119.GAA28113@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-11.txt Date: Tue, 29 Oct 2002 06:19:15 -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 : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-11.txt Pages : 26 Date : 2002-10-28 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-2373 'IP Version 6 Addressing Architecture'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.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: <2002-10-28163558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28163558.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 03:28:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TBSP29025593; Tue, 29 Oct 2002 03:28:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TBSP1m025590; Tue, 29 Oct 2002 03:28:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TBSL29025582 for ; Tue, 29 Oct 2002 03:28:21 -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 g9TBSUMq013689 for ; Tue, 29 Oct 2002 03:28:30 -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 EAA00356 for ; Tue, 29 Oct 2002 04:28:24 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9TBS6012679; Tue, 29 Oct 2002 13:28:06 +0200 Date: Tue, 29 Oct 2002 13:28:06 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Margaret Wasserman , Michel Py , Keith Moore , , Subject: Forwarding packets with site-local source [Re: Choices to go forward with SL] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Oct 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > (Note: this message is not directly related to the main point of this > thread.) > > >>>>> On Tue, 29 Oct 2002 08:51:12 +0200 (EET), > >>>>> Pekka Savola said: > > > I'm not even sure if we could get addrarch to draft standard, have folks > > implemented these two: > > > --8<-- > > Routers must not forward any packets with site-local source or > > destination addresses outside of the site. > > --8<-- > > > None of the implementations I use certainly haven't, and this has been > > around for a time now, even since RFC1884.. > > KAME can do this. Note that KAME only supports this through manual configuration (and a fix) -- clarified in off-the-list discussion. To be compliant with the paragraph: Routers must not forward any packets with site-local source or destination addresses outside of the site. Note: it does not say 'packets from the site' (implying configuration of the site) but 'with site-local source'. That strongly implies explicit configuration will not satisfy. I expect an implementation must automatically, without any configuration, drop e.g. packets received under the following steps: 1) a router is configured to advertise a site-local prefix 2) a node configures a site-local address and starts sending out traffic 3) router drops it or forwards it (using some logic). Or even: 1) node just blindly configures fec0::1 and starts sending traffic using it, testing how far it will go. A valid scenario here could be that site-locals would be used inside one link only -- no config at all in the router -- but the route must disallow propagation of site-locals through default route if something fails. You may ask: how is this possible? we don't have any site-border discovery mechanisms? I say: exactly, that's why the paragraph is so ridiculous! The only easy and compliant implementation I could think of would be discarding all site-locals unless some links are explicitly configured to be part of a site. (Note: one could use some logic, e.g. require all interfaces where site-local traffic is valid must have site-local addresses to auto-discover the border between globals and site-locals.. but that would have quite a few assumptions I believe) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 04:54:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TCsS29025883; Tue, 29 Oct 2002 04:54:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TCsRGG025882; Tue, 29 Oct 2002 04:54:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TCsO29025875 for ; Tue, 29 Oct 2002 04:54: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 g9TCsXbB025088 for ; Tue, 29 Oct 2002 04:54:34 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12535 for ; Tue, 29 Oct 2002 04:54:28 -0800 (PST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9TCsOup011016 for ; Tue, 29 Oct 2002 07:54:24 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 29 Oct 2002 07:54:08 -0500 Message-ID: <3DBE846D.3090709@nc.rr.com> Date: Tue, 29 Oct 2002 07:51:57 -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: ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Pekka Savola wrote: > On Tue, 29 Oct 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>(Note: this message is not directly related to the main point of this >>thread.) >> >> >>>>>>>On Tue, 29 Oct 2002 08:51:12 +0200 (EET), >>>>>>>Pekka Savola said: >>>>>> >>>I'm not even sure if we could get addrarch to draft standard, have folks >>>implemented these two: >> >>>--8<-- >>> Routers must not forward any packets with site-local source or >>> destination addresses outside of the site. >>>--8<-- >> >>>None of the implementations I use certainly haven't, and this has been >>>around for a time now, even since RFC1884.. >> >>KAME can do this. I have implemented it as well. > > > Note that KAME only supports this through manual configuration (and a > fix) -- clarified in off-the-list discussion. > > To be compliant with the paragraph: > > Routers must not forward any packets with site-local source or > destination addresses outside of the site. > > Note: it does not say 'packets from the site' (implying configuration of > the site) but 'with site-local source'. That strongly implies explicit > configuration will not satisfy. I don't read it that way at all. I interpret that to mean, if the router is configured as a site-border router it must not forward those packets out of the site. The behavior is as defined in Section 5 of the scoped addr arch which is all interfaces are in the same site, unless explicitly configured by an administrator. > > I expect an implementation must automatically, without any configuration, > drop e.g. packets received under the following steps: > > 1) a router is configured to advertise a site-local prefix > 2) a node configures a site-local address and starts sending out traffic > 3) router drops it or forwards it (using some logic). > > Or even: > > 1) node just blindly configures fec0::1 and starts sending traffic using > it, testing how far it will go. > > A valid scenario here could be that site-locals would be used inside one > link only -- no config at all in the router -- but the route must disallow > propagation of site-locals through default route if something fails. That does not follow from the discussion in scoped addr arch. Of course, this should be clarified in addr arch when we decide on the SL content of that document. > > > You may ask: how is this possible? we don't have any site-border > discovery mechanisms? > > I say: exactly, that's why the paragraph is so ridiculous! > > The only easy and compliant implementation I could think of would be > discarding all site-locals unless some links are explicitly configured to > be part of a site. From the discussion I have read, it seems that it would be more that we are assuming that all interfaces are in the same site unless explicitly configured. 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 Oct 29 05:00:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TD0s29025938; Tue, 29 Oct 2002 05:00:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TD0stl025937; Tue, 29 Oct 2002 05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TD0p29025930 for ; Tue, 29 Oct 2002 05:00:51 -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 g9TD10Mq024815 for ; Tue, 29 Oct 2002 05:01:00 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15141 for ; Tue, 29 Oct 2002 05:00:55 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA08032; Tue, 29 Oct 2002 05:00:39 -0800 (PST) Message-Id: <5.1.0.14.2.20021029075748.07aaccb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 07:59:49 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Dan Lanciani" , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B637@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is some more information from my unpublished document on site-locals. Maybe after Atlanta I'll finally get around to publishing it... This section concerns the suppose advantages that IPv6 site-local addresses have for long-lived connections (please debunk if I'm mistaken!). Margaret A much-touted advantage of site-local addressing is that it will allow site-local, long-lived IPv6 connections to survive renumbering of global prefixes. Global prefix renumbering could happen when an organization switches from one ISP to another, or when an ISP renumbers its internal network, changing the prefixes assigned to customers. There is, however, a potential risk to using site-local addresses for long-lived connections. Those connections may fail when a site becomes partitioned, even if global connectivity is still available between the partitions. To make a wise decision about whether to use site-local or global addresses for long-lived intra-site connections, it is necessary to weigh the expected frequency of renumbering against the expected frequency of site partitioning. Since the frequency of these events will vary widely between sites, there is no single answer that would be best for all sites. It should also be noted that there are many reasons why a long- lived connection might fail, including network outages, system restarts or local network reconfiguration. Any application that depends upon the reliability of a long-lived connection will still need to include a mechanism to re-initiate a lost connection. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 05:15:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDF129026205; Tue, 29 Oct 2002 05:15:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TDF1J0026204; Tue, 29 Oct 2002 05:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDEv29026197 for ; Tue, 29 Oct 2002 05:14:57 -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 g9TDF6bB027823 for ; Tue, 29 Oct 2002 05:15:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06884 for ; Tue, 29 Oct 2002 06:15:00 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TDDY024967; Tue, 29 Oct 2002 08:13:34 -0500 (EST) Message-Id: <200210291313.g9TDDY024967@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Margaret Wasserman , Michel Py , Keith Moore , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Choices to go forward with SL [RE: Limiting the Use of Site-Local] In-reply-to: (Your message of "Tue, 29 Oct 2002 08:51:12 +0200.") Date: Tue, 29 Oct 2002 08:13:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I also think it would be a good idea to amend the addrarch document to discourage use of SLs except on isolated networks. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 05:18:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDI529026250; Tue, 29 Oct 2002 05:18:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TDI5Rk026249; Tue, 29 Oct 2002 05:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDI229026242 for ; Tue, 29 Oct 2002 05:18:02 -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 g9TDIBbB028304 for ; Tue, 29 Oct 2002 05:18:11 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15405 for ; Tue, 29 Oct 2002 06:18:05 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA14907; Tue, 29 Oct 2002 05:17:59 -0800 (PST) Message-Id: <5.1.0.14.2.20021029081049.07acf8a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 08:17:37 -0500 To: "Brian Zill" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local 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 > >One advantage of having scoped addresses defined in the IPv6 >architecture from the start is that applications can know not to pass >them outside of their scope. If we instead suggest that people >firewall/filter off random portions of the global address space, then >apps will blindly pass those addresses around in the data stream, >mistakenly thinking that they are real global addresses. Only having >dedicated scoped address space allows apps to do the right thing. I don't agree... When one sections off a portion of the global address space and an application can't reach it, that is the intended behaviour. The application has an unambiguous address, but it just can't reach the addressed node. This will be a frequent occurence (due to firewalls, network outages, etc.) and applications will have to deal with it appropriately (error message to the user, or whatever). I'm not actually against the idea of private networks, and I agree that they are necessary for security. I just think that they should use global addresses, not site-local addresses. Site-local addresses create _overlapping_ private address spaces. When SLs are sent outside of a site, they become ambiguous (or just plain wrong). So, it is not possible to know which host a corresponds to a particular site-local address unless you also know which site the address applies to. This creates a set of problems that I think we should avoid by not using site-local on globally-connected networks. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 05:27:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDRZ29026431; Tue, 29 Oct 2002 05:27:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TDRZTR026430; Tue, 29 Oct 2002 05:27:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDRW29026420 for ; Tue, 29 Oct 2002 05:27:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TDRfMq028764 for ; Tue, 29 Oct 2002 05:27:41 -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 GAA13190 for ; Tue, 29 Oct 2002 06:27:35 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA18779 for ; Tue, 29 Oct 2002 05:27:30 -0800 (PST) Message-Id: <5.1.0.14.2.20021029082054.0331fd90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 08:24:08 -0500 To: From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local 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 A couple of people have asked off-line, and I thought it would be good to clarify... _None_ of my mail on this thread (or the previous Node Requirements thread) has been made in my "official" capacity as a WG chair. I'm just stating my personal opinions about the technical issues with site-locals and what I think that the WG should do. In the end, I will abide by the consensus opinion of the WG regarding these issues, even if the WG doesn't agree with me (as you often don't :-)). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 05:27:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDRw29026450; Tue, 29 Oct 2002 05:27:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TDRwnf026449; Tue, 29 Oct 2002 05:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDRq29026433 for ; Tue, 29 Oct 2002 05:27:52 -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 g9TDS1bB029405 for ; Tue, 29 Oct 2002 05:28:01 -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 GAA13323 for ; Tue, 29 Oct 2002 06:27:56 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA18808; Tue, 29 Oct 2002 05:27:31 -0800 (PST) Message-Id: <5.1.0.14.2.20021029082600.0332d900@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 08:27:36 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Michel Py , Keith Moore , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >You may ask: how is this possible? we don't have any site-border >discovery mechanisms? We don't need an autoconfiguration mechanism for every feature of the IPv6 specifications. If routers can be configured to act as site-border routers (and not forward site-local addresses outside of the site), this is all that the spec requires. It doesn't require that the configuration be automatic, or even simple to configure. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 05:35:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDZG29026660; Tue, 29 Oct 2002 05:35:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TDZGGo026659; Tue, 29 Oct 2002 05:35:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TDZD29026652 for ; Tue, 29 Oct 2002 05:35: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 g9TDZMMq000124 for ; Tue, 29 Oct 2002 05:35:22 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09877 for ; Tue, 29 Oct 2002 06:35:17 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA22031; Tue, 29 Oct 2002 05:34:59 -0800 (PST) Message-Id: <5.1.0.14.2.20021029082933.07ad2bf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 08:36:26 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Choices to go forward with SL [RE: Limiting the Use of Site-Local] Cc: Pekka Savola , Michel Py , Keith Moore , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210291313.g9TDDY024967@astro.cs.utk.edu> References: <(Your message of "Tue, 29 Oct 2002 08:51:12 +0200.") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think that the addr arch is the right place to do this. If we start defining how each type of address in the addr arch will be used, we will basically end-up moving most of the scoped addressing architecture document into the addressing architecture, and it will never be finished. Also, we don't have any declared consensus about how/if we will limit site-locals at all... The current addr arch is light-years ahead of the RFC version, and I think that we need to get it published. I'd like to keep talking about the site-local issues, and I hope that we can get some changes made in the scoped addressing architecture. Part of the discussion of those changes should (and will) be a discussion of what impact those changes would have on other IPv6 documents, including (possibly) the addr arch, address autoconf, etc. If/when we have agreement on what changes to make, that may include changes to other documents. In the meantime, though, I don't think we should hold up the addressing architecture. It has been held up, literally, for years because there is always some ongoing discussion that _might_ require changes to it (most of them don't), and I think that has to stop. Margaret At 08:13 AM 10/29/02, Keith Moore wrote: >I also think it would be a good idea to amend the addrarch document to >discourage use of SLs except on isolated networks. > >Keith >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 06:12:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEC929027078; Tue, 29 Oct 2002 06:12:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TEC8fd027077; Tue, 29 Oct 2002 06:12:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEC429027070 for ; Tue, 29 Oct 2002 06:12:04 -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 g9TECDbB005760 for ; Tue, 29 Oct 2002 06:12:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03045 for ; Tue, 29 Oct 2002 07:12:07 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TEAk025423; Tue, 29 Oct 2002 09:10:46 -0500 (EST) Message-Id: <200210291410.g9TEAk025423@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , Alain Durand , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 16:09:05 +1100.") <200210290509.g9T595BM026467@drugs.dv.isc.org> Date: Tue, 29 Oct 2002 09:10:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And application break when you use non-globally-routed GA's. > > People want permanent private address space be that multiply > allocated (SL/1918) or non-globally-routed global address > space (NGRGAS). Passing addresses in either is not > guaranteed to work with every node. no. but if you use globals for all addresses then you can get a reasonable separation of function between apps/hosts and the network - if you can't communicate between two nodes it's either because part of the network is down or because the network doesn't let you. either way, it's not something that the application can be expected to solve. so with globals the application no longer has to be responsible for trying to work around deficiencies in the addressing scheme. > NGRGAS removes one > address maps to multiple nodes yes. > but it does not help identify > if two nodes share a common site though you can identify > if a node shares your site. the node shouldn't need to do this. the app sends to an address. if it gets there, it gets there. if not, it's not the app's problem. the app can try to fail-over to other addresses if they exist, but the first address should work with high probability. in other words, we need to abandon this idea that a host can have an arbitrary number of addresses with varying scopes and lifetimes and connectivity, and it's up to hosts/apps to sort out which one is best to use. instead hosts should have a small number of addresses (most of the time just 1, 2 during renumbering periods) each of which is valid from anywhere, and the network should decide how best to get the traffic there. (no I'm not suggesting to deprecate LLs but normal apps should use them only as a last resort or when explicitly configured to do so.) > NGRGAS also requires a registry to allocate the address space. if we tried I'm sure we could come up with a way to allocate non-routable globals without a registry. I'm convinced that this is vital for the long-term success of IPv6. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 06:16:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEGH29027134; Tue, 29 Oct 2002 06:16:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TEGHtC027133; Tue, 29 Oct 2002 06:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEFf29027123 for ; Tue, 29 Oct 2002 06:16:13 -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 g9TEFobB006417 for ; Tue, 29 Oct 2002 06:15:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01599 for ; Tue, 29 Oct 2002 07:15:44 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TEFb025500; Tue, 29 Oct 2002 09:15:37 -0500 (EST) Message-Id: <200210291415.g9TEFb025500@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 21:59:22 PST.") Date: Tue, 29 Oct 2002 09:15:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One advantage of having scoped addresses defined in the IPv6 > architecture from the start is that applications can know not to pass > them outside of their scope. NO. 1. applications don't know where their scope ends. 2. expecting applications to know about network topology drastically increases their complexity without any recognizable benefits. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 06:21:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TELZ29027172; Tue, 29 Oct 2002 06:21:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TELY4D027171; Tue, 29 Oct 2002 06:21:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TELU29027164 for ; Tue, 29 Oct 2002 06:21:31 -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 g9TELeMq007014 for ; Tue, 29 Oct 2002 06:21:40 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05032 for ; Tue, 29 Oct 2002 07:21:34 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TELU025537; Tue, 29 Oct 2002 09:21:30 -0500 (EST) Message-Id: <200210291421.g9TELU025537@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issues 4, 5, & 6 In-reply-to: (Your message of "Mon, 28 Oct 2002 23:03:10 PST.") Date: Tue, 29 Oct 2002 09:21:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Of course I think it should be mandatory. Support for multiple addresses > is one of IPv6's great features but there has to be some standardization > to prevent it from being an unpredictable mess. Default Address > Selection is definitely needed. > support for multiple addresses is IPv6's Achilles heel. they need to be tolerated to make renumbering work, and LLs are indeed useful for bootstrapping, etc. but expecting multiple addrs to solve the routing scalability problem (just to take one example) was a grave error. I'm all for consistent behavior between implementations, but we're deluded if we think that default address selection is going to magically make the problems that come with each host having several addresses of varying scopes/connectivity/lifetime disappear. no set of default rules can cope with that complexity. that and the current rules are broken because they favor scoped addresses over globals. scoped addresses should never be used except as a last resort. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 06:34:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEYg29027427; Tue, 29 Oct 2002 06:34:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TEYgoZ027426; Tue, 29 Oct 2002 06:34:42 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEYd29027419 for ; Tue, 29 Oct 2002 06:34:39 -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 g9TEYmMq013571 for ; Tue, 29 Oct 2002 06:34:48 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12881 for ; Tue, 29 Oct 2002 07:34:43 -0700 (MST) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9TEYPiZ027277 for ; Tue, 29 Oct 2002 09:34:26 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 29 Oct 2002 09:34:05 -0500 Message-ID: <3DBE9D60.9020201@nc.rr.com> Date: Tue, 29 Oct 2002 09:38:24 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <200210291415.g9TEFb025500@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >>One advantage of having scoped addresses defined in the IPv6 >>architecture from the start is that applications can know not to pass >>them outside of their scope. I have heard this stated by several people before and I am not sure how apps are supposed to know this. Especially since it was stated that each nodes view of what is a site is independent of other nodes. > > > NO. > > 1. applications don't know where their scope ends. Are people assuming that a functionality similar to MZAP (RFC 2776) is going to be used to advertise site information? 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 Oct 29 06:58:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEwd29027624; Tue, 29 Oct 2002 06:58:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TEwciL027623; Tue, 29 Oct 2002 06:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TEwY29027616 for ; Tue, 29 Oct 2002 06:58:34 -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 g9TEwhbB013708 for ; Tue, 29 Oct 2002 06:58:43 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28263 for ; Tue, 29 Oct 2002 07:58:38 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TEwZ025599; Tue, 29 Oct 2002 09:58:35 -0500 (EST) Message-Id: <200210291458.g9TEwZ025599@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Mon, 28 Oct 2002 23:00:03 PST.") Date: Tue, 29 Oct 2002 09:58:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Gee whiz, I really can not keep up with this thread. > > Why did I call it "craziness"? > > First, because it's not productive to revisit old design decisions. > Scoped addresses and the notion that nodes would have multiple addresses > of different scopes are design decisions from many years ago. yes, they're perfect examples of second-system effect. to the extent that we can deprecate them we're doing everyone a favor and making IPv6 much more usable. IPv6 is a good design with a few warts which we'd be better off without. A6 was one wart. SLs are another. fortunately we can eliminate the warts without doing harm to IPv6. > Second, scoped addresses are an important part of the IPv6 architecture > because they reflect today's internet architecture. when you have a train wreck, you don't call the resulting jumble of cars and debris 'architecture'. > The internet is no > longer a fully-connected network of nodes with static addresses. (I get > the impression that some participants in this thread would like to turn > the clock back 20 years!) The world is more complicated now. Sites have > strong boundaries; firewalls and two-faced DNS are commonplace for > enterprise networks. yes, but people have had to resort to poor solutions because of a shortage of address space in v4. that and some really bad ideas have been tried which are now being found wanting. nobody is suggesting that sites abandon firewalls, or that sites be forced to advertise all of their hosts' addresses using DNS. what is being argued rather forcefully is that having site-local addresses (and having apps be expected to use them) adds a lot of complexity without providing a significant benefit in return. > The idea of restricting site-locals to completely disconnected networks > doesn't make much sense to me. It's like saying you can have them but > not really. no it's like saying that SLs are a bad idea except perhaps for a few corner cases where they don't do much harm - and rather than burdening everyone with having to deal with SLs we should discourage their use except in those corner cases. in other words, we're just recognizing reality. >How would we handle intermittently connected sites, or > partially connected sites? give them globals, of course. > What would happen when a network that is > using site-locals gains global connectivity? same as when a network changes providers. they have to renumber, and there's a transition period during which both kinds of addrs are used. > This seems like a recipe > for encouraging v6 NAT, which is not something we want. no more than any other kind of renumbering. we need to work out a complete and convincing renumbering solution but SLs aren't a part of that. > In my opinion, IPv6's explicit architectural support for multiple > addresses and scoped addresses are two of its advantages over IPv4. > Because they're baked in from the start, applications can do the right > thing with scoped addresses. no, it doesn't follow. first because nobody has been able to define what the "right thing" is - or to be more accurate, it looks like the "right thing" is "avoid SLs at all costs". second because this essentially expects apps to perform routing in the absence of any routing information, and anyway that's the network's job. in other words, just because SLs have been in the address architecture for a long time doesn't mean that their effects, or how to use them, were understood. when apps people start looking at these things the emerging understanding is that they're a bad idea except for some corner cases where apps don't have to deal with them anyway. one way to put it is that SLs should be discouraged to the extent that a default set of addr selection rules (_not_ the ones currently in effect) will work just fine. > And one way or another they will be there > eventually (look at how scoped addresses have crept into IPv4), so it's > better if applications that need to know about them are coded that way > from the start. about the only benefit to having them be visible to apps is so that apps can avoid using them - and this only works if sites are discouraged from using them. expecting apps to make reasonable decisions about which addrs to use in which contexts is extremely naive because apps simply don't have access to the necessary information to inform those decisions and because they don't want to absorb that complexity even if they did have access to that information. > In addition to the main architectural point above, there are some > specific advantages of site-local addresses that others have mentioned, > but let me put my own spin on them: > > 1. Site renumbering. Preserving long-lived connections across > renumbering is not so compelling - I think most renumbering events can > be planned for a large enough time-scale. More interesting is that > various random static configurations that use site-locals do not have to > be tracked down and updated. I agree that this is an interesting idea. > 2. Auto firewall. The site boundary is automatically a firewall for the > site-local prefix. actually it seems about as easy for routers to implement a similar function for globals. what SLs give you is the ability to mix and match routable and non-routable addrs and you can control whether a host or app has external acces depending on which address you tell that host or app to use. but this isn't a very secure way of doing access control. > Distributed > applications that send around addresses do have to cognizant of scoped > addresses. However this is not hard to deal with. For example I checked > on how one such distributed application that is being built at MS > handles this issue. The application looks at the scope of the > correspondent and sends its addresses of matching scope. In other words, > when talking to a global address you send your global addresses and when > talking to a site-local address you send your site-local addresses. it doesn't work. then you can't do referrals between sites. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 07:02:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TF2N29027650; Tue, 29 Oct 2002 07:02:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TF2NAv027649; Tue, 29 Oct 2002 07:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TF2J29027642 for ; Tue, 29 Oct 2002 07:02:19 -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 g9TF2SMq018338 for ; Tue, 29 Oct 2002 07:02:28 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22627 for ; Tue, 29 Oct 2002 07:02:22 -0800 (PST) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9TF2DL29441; Tue, 29 Oct 2002 10:02:13 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9TF2C856216; Tue, 29 Oct 2002 10:02:12 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA00415; Tue, 29 Oct 2002 10:02:09 -0500 (EST) Subject: RE: Limiting the Use of Site-Local From: Steven Blake To: Margaret Wasserman Cc: Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20021029081049.07acf8a0@mail.windriver.com> References: <5.1.0.14.2.20021029081049.07acf8a0@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 29 Oct 2002 10:02:06 -0500 Message-Id: <1035903729.35924.23.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-10-29 at 08:17, Margaret Wasserman wrote: > Site-local addresses create _overlapping_ private address > spaces. When SLs are sent outside of a site, they become > ambiguous (or just plain wrong). So, it is not possible to > know which host a corresponds to a particular site-local > address unless you also know which site the address applies > to. This creates a set of problems that I think we should > avoid by not using site-local on globally-connected networks. SLs where originally defined as overlapping, but with the recent changes in addr-arch this is no longer necessary. Site-locals can and should be mutated into non-globally routable global address space (NGRGAS). The inability to operate stable addresses in parallel with provider addresses is going to make the the deployment of IPv6 NAT more likely, not less. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 07:31:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFVA29027935; Tue, 29 Oct 2002 07:31:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TFVAfp027934; Tue, 29 Oct 2002 07:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFV629027927 for ; Tue, 29 Oct 2002 07:31:06 -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 g9TFVCbB019575 for ; Tue, 29 Oct 2002 07:31:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10691 for ; Tue, 29 Oct 2002 07:31:06 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TFTb026765; Tue, 29 Oct 2002 10:29:38 -0500 (EST) Message-Id: <200210291529.g9TFTb026765@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , Pekka Savola , Michel Py , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Choices to go forward with SL [RE: Limiting the Use of Site-Local] In-reply-to: (Your message of "Tue, 29 Oct 2002 08:36:26 EST.") <5.1.0.14.2.20021029082933.07ad2bf0@mail.windriver.com> Date: Tue, 29 Oct 2002 10:29:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The current addr arch is light-years ahead of the RFC version, and > I think that we need to get it published. I understand the need to publish it, I just don't want it to mislead people into thinking that there are actually valid use cases for all of the kinds of addresses it defines. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 07:38:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFca29028016; Tue, 29 Oct 2002 07:38:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TFca7h028015; Tue, 29 Oct 2002 07:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFcW29028007 for ; Tue, 29 Oct 2002 07:38: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 g9TFcgbB021083 for ; Tue, 29 Oct 2002 07:38:42 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15833 for ; Tue, 29 Oct 2002 07:38:36 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA25199; Tue, 29 Oct 2002 07:38:30 -0800 (PST) Message-Id: <5.1.0.14.2.20021029101044.07abdec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 10:39:56 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local 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 >First, because it's not productive to revisit old design decisions. >Scoped addresses and the notion that nodes would have multiple addresses >of different scopes are design decisions from many years ago. I can understand this argument, but I don't think it fully applies here... We did decide to include site-local addressing in the architecture years ago, but only fairly recently did we start documenting how it would actually _work_. The scoped addressing architecture is still an I-D (not any sort of RFC), and I think it is appropriate to consider (and even re-consider) the architecture described in that I-D. >Second, scoped addresses are an important part of the IPv6 architecture >because they reflect today's internet architecture. The internet is no >longer a fully-connected network of nodes with static addresses. (I get >the impression that some participants in this thread would like to turn >the clock back 20 years!) The world is more complicated now. Sites have >strong boundaries; firewalls and two-faced DNS are commonplace for >enterprise networks. Addresses occasionally change. I think that one of the goals of IPv6 is to enable the simplification of the Internet architecture. Maybe this is naive and idealistic, but I hope that, when we turn the clock forward 20 years, we'll find a flatter and simpler Internet architecture than we have today, enabled by IPv6. One way that I think we could help to make this change is be advocating the use of globally-unique addresses on private networks. >The idea of restricting site-locals to completely disconnected networks >doesn't make much sense to me. It's like saying you can have them but >not really. How would we handle intermittently connected sites, or >partially connected sites? What would happen when a network that is >using site-locals gains global connectivity? This seems like a recipe >for encouraging v6 NAT, which is not something we want. These are valid questions/concerns, and I think it makes sense to discuss them. However, I'm not sure that we know the answers to all of these questions, even if site-locals are used side-by-side with global addresses. How would that work for intermittently connected sites? Partially-connected sites? Sites that gain global connectivity? Sites that renumber? Etc. One of the issues with having a "tool" like site-local addressing is that it is easy to see it as a panacea to solve a huge number of problems. In actuality, site-local addressing will not solve the bulk of the problems you've listed without other things also being defined -- like explicit support for site-locals in applications, and in the DNS. >In my opinion, IPv6's explicit architectural support for multiple >addresses and scoped addresses are two of its advantages over IPv4. >Because they're baked in from the start, applications can do the right >thing with scoped addresses. And one way or another they will be there >eventually (look at how scoped addresses have crept into IPv4), so it's >better if applications that need to know about them are coded that way >from the start. Unfortunately, I don't think that most IPv6 applications are (or will be) coded from scratch. In general, folks are trying to port IPv4 applications, and the need to understand all of the issues surrounding site-local addresses will represent a significant hurdle and/or be ignored -- both of which are bad. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 07:39:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFdA29028037; Tue, 29 Oct 2002 07:39:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TFdARE028036; Tue, 29 Oct 2002 07:39:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFd729028029 for ; Tue, 29 Oct 2002 07:39:07 -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 g9TFdGMq025398 for ; Tue, 29 Oct 2002 07:39:16 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25512 for ; Tue, 29 Oct 2002 08:39:10 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 19AFA2D86; Tue, 29 Oct 2002 10:39:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 10:39:10 -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: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 10:39:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B63B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing RS Reply Timing for Mobile IPv6 Thread-Index: AcJ1KqF69ur7U4RLR+i3VkNjnkr7oQKNCHMg From: "Bound, Jim" To: "James Kempf" , "Thomas Narten" Cc: X-OriginalArrivalTime: 29 Oct 2002 15:39:10.0064 (UTC) FILETIME=[52FCA700:01C27F61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TFd729028030 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, ........................................Determination of how this router is designated is outside the scope of this document. An RA that is immediately unicast to the sender rather than delayed is known as a "fast RA". I do not believe it should be outside the scope of this draft. I think it imperative that this be defined clearly and a method proposed before FAST RA can be bought into by IPv6 implementors. I also believe at this time the IESG should require a fairly good set of reports from multiple implementations of this and other proposals for wireless efforts that want to change DAD parameters and extend attributes to ND and Stateless Addrconf. Right now the only work within this space that has received the test of fire at UNH, ETSI, or TAHI as examples is MIPv6. These tests beat hard on IPv6 implementation enhancements as was just done for MIPv6 D-18 in Sophia Antipolis at ETSI. I would suggest to the IESG doing any changes to ND or Addrconf without serious hard core testing from this work is dangerous. If you, I, and others believe this is important then the code will get done for this and Optimistic DAD and show up at the tests. Otherwise this is purely a research and at best AD exercise. IPv6 is now being deployed we cannot mess with DAD or Addr Conf in casual ways any more than we do with IP (for v4), TCP, or RTT algrorithm for TCP as examples. I also believe all these efforts should begin to think like MIPv6 has and that is they are separate documents and I strongly am against any enhancments to ND or Addrconf from Fast RA, Optimistic DAD etc. They should be new RFCs. All this also presents new security problems too that does not exist in current ND and Addrconf on wired links. The base reason is that these mess with the ND architecture and wired links that are firewalled or PKI protected are more insulated than say 802.11b. That being said I would like to see all security sections for this work define what new security problems exist simply because of this behavior not just say exists now in DAD or whatever. None of these options should be permitted for wire links (status quo) at all. That gives me an idea at least how the router to do Fast RA should be defined. I would also like to see hard core router or switch "PRODUCT" developers comment on this work and other work. I know routing code but not like those that build ASICs and the like. I would like to hear them say the pain and gain they feel or see from this strategy. /jim [Have you ever seen the rain coming down on a sunny day] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 07:52:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFq429028220; Tue, 29 Oct 2002 07:52:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TFq4ik028219; Tue, 29 Oct 2002 07:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TFq129028212 for ; Tue, 29 Oct 2002 07:52:01 -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 g9TFqAMq027801 for ; Tue, 29 Oct 2002 07:52:10 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14686 for ; Tue, 29 Oct 2002 08:52:04 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA05488; Tue, 29 Oct 2002 07:51:52 -0800 (PST) Message-Id: <5.1.0.14.2.20021029104856.07a9ebd0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 10:50:33 -0500 To: Steven Blake From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <1035903729.35924.23.camel@newcastle.torrentnet.com> References: <5.1.0.14.2.20021029081049.07acf8a0@mail.windriver.com> <5.1.0.14.2.20021029081049.07acf8a0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A >SLs where originally defined as overlapping, but with the recent changes >in addr-arch this is no longer necessary. Site-locals can and should be >mutated into non-globally routable global address space (NGRGAS). By "overlapping", I meant that the addresses overlap -- two sites could both use the address SL:1::1, and those addresses would refer to two different hosts. >The inability to operate stable addresses in parallel with provider >addresses is going to make the the deployment of IPv6 NAT more likely, >not less. Using NGRGAS's would also have the advantage of working properly when two sites merge... Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 08:25:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGPD29028419; Tue, 29 Oct 2002 08:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TGPD0g028418; Tue, 29 Oct 2002 08:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGP929028411 for ; Tue, 29 Oct 2002 08:25: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 g9TGPIMq005278 for ; Tue, 29 Oct 2002 08:25:18 -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 IAA12983 for ; Tue, 29 Oct 2002 08:25:12 -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 g9TGOnRa050198 for ; Tue, 29 Oct 2002 17:25:00 +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 g9TGOjB6100330 for ; Tue, 29 Oct 2002 17:24:46 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45692 from ; Tue, 29 Oct 2002 17:24:44 +0100 Message-Id: <3DBEB641.7EBBCE50@hursley.ibm.com> Date: Tue, 29 Oct 2002 17:24:33 +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: Comments on IPv6 Flow Label Last Call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It seems I was accidentally dropped from the mailing list just before the last call went out. In addition to Jarno's comments, let me add to what jak said: ... > > - Allowing a specific flow label value to be assigned via a signaling > > protocol to identify flows with different source and destination > > addresses. > > > > This is a concern. I agree that keeping a simple flow label usage might be > better for now, until we have more experience. However, I can also see an > argument that it might simplify signaling in certain cases, for example, > multi-user voice sessions such as a teleconference. There are two points here. One is that we have to allow for SCTP's multiple addresses. The current text may be a little unclear on this. Another is that not everybody, and not every QoS mechanism, agrees on what a "flow" is - and we didn't want to be too restrictive. However, the text does seem to need a fix. > > > The draft may be trying to accommodate uses of the flow label that were not > > agreed to by the working group. Defiantly, yes. I don't think it's for this WG to second-guess future usages. We should leave as many options open as possible. > > > > There are a number of other areas in the draft that need additional > > discussion and/or clarification. These include: > > > > - No default time out for the life time for specific flow label values. > > - No requirement that signaling mechanisms must include a lifetime > > when providing flow label setup information. > > I believe the issue here is flow label state, and not flow labels per se. I > agree that the document should state that flow label state should be soft state, > and that there should be a requirement that flow label state have a specific > lifetime. Personally, I agree as long as it's "should" in both cases. > > However, as the document is trying to set up requirements, I believe specifying > a default lifetime for all applications would be inappropriate. I think it is > enough to require that signaling protocols and applications specify a default. > The default may differ depending on the application. But the default needs to be known downstream, where there may be no specific knowledge about the application. So I think a default is needed. > > > > - No default mechanisms if flow label values requested via a signaling > > mechanisms conflict with existing flow label values. Surely the request simply fails? But it's not clear that this WG has any business saying how the signalling should work. > > - Security considerations need to discuss the impact of labeling flows > > of encrypted traffic. > > > > It is not immediately clear to me whether additional requirements in this area > are needed, but it would not hurt to spend some time considering these. IPSEC already considered this when deciding not to cover the flow label field. I'm really not sure what else there is to say. On all these points, if change is needed, please send text. 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 Oct 29 08:28:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGSx29028465; Tue, 29 Oct 2002 08:28:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TGSxHS028464; Tue, 29 Oct 2002 08:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGSt29028457 for ; Tue, 29 Oct 2002 08:28: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 g9TGT4bB001247 for ; Tue, 29 Oct 2002 08:29:05 -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 JAA03423 for ; Tue, 29 Oct 2002 09:28:58 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9TGStL15221; Tue, 29 Oct 2002 18:28:56 +0200 Date: Tue, 29 Oct 2002 18:28:55 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] In-Reply-To: <3DBE846D.3090709@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Oct 2002, Brian Haberman wrote: > > Note that KAME only supports this through manual configuration (and a > > fix) -- clarified in off-the-list discussion. > > > > To be compliant with the paragraph: > > > > Routers must not forward any packets with site-local source or > > destination addresses outside of the site. > > > > Note: it does not say 'packets from the site' (implying configuration of > > the site) but 'with site-local source'. That strongly implies explicit > > configuration will not satisfy. > > I don't read it that way at all. I interpret that to mean, if the > router is configured as a site-border router it must not forward those > packets out of the site. That kind of interpretation is easy (== activation logic in the implementation is simple) , but really, totally useless I believe. The promise of using site-locals is that they will not propagate globally. Routers must make sure they don't do that, even without being configured as site-border routers. If this wasn't true, nobody should be able to use site-locals even without relatively clean conscience, as nobody could be sure there _is_ a router that's blocking illegally-sourced site-locals from coming to my site or vice versa. The paragraph requires clarification for sure. > The behavior is as defined in Section 5 of the scoped addr arch which > is all interfaces are in the same site, unless explicitly configured > by an administrator. Scoped arch draft is irrelevant from the perspective of addrarch (independence) IMO. > > 1) node just blindly configures fec0::1 and starts sending traffic using > > it, testing how far it will go. > > > > A valid scenario here could be that site-locals would be used inside one > > link only -- no config at all in the router -- but the route must disallow > > propagation of site-locals through default route if something fails. > > That does not follow from the discussion in scoped addr arch. Of > course, this should be clarified in addr arch when we decide on the > SL content of that document. Better: _addrarch_ shouldn't say anything at all like that because we don't know how to do it (or can't write it down). > > You may ask: how is this possible? we don't have any site-border > > discovery mechanisms? > > > > I say: exactly, that's why the paragraph is so ridiculous! > > > > The only easy and compliant implementation I could think of would be > > discarding all site-locals unless some links are explicitly configured to > > be part of a site. > > From the discussion I have read, it seems that it would be more that > we are assuming that all interfaces are in the same site unless > explicitly configured. The risk of site-local leakage is _way_ too big that way. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 08:34:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGYZ29028558; Tue, 29 Oct 2002 08:34:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TGYYqf028557; Tue, 29 Oct 2002 08:34:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TGYV29028550 for ; Tue, 29 Oct 2002 08:34:31 -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 g9TGYeMq007684 for ; Tue, 29 Oct 2002 08:34:41 -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 JAA13664 for ; Tue, 29 Oct 2002 09:34:35 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9TGYOL15281; Tue, 29 Oct 2002 18:34:24 +0200 Date: Tue, 29 Oct 2002 18:34:24 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] In-Reply-To: <5.1.0.14.2.20021029082600.0332d900@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tailed Cc: list a bit. On Tue, 29 Oct 2002, Margaret Wasserman wrote: > >You may ask: how is this possible? we don't have any site-border > >discovery mechanisms? > > We don't need an autoconfiguration mechanism for every feature of > the IPv6 specifications. If routers can be configured to act as > site-border routers (and not forward site-local addresses outside > of the site), this is all that the spec requires. It doesn't > require that the configuration be automatic, or even simple to > configure. People have read it differently, that's for sure. Some read it (many): "if I configure a site here, I must also block site-locals from spreading out or false site-locals coming in" Some others read it: "if I use site-locals here, my upstream router will block the site-local addresses from spreading out and prevent anyone from spoofing site-locals to my site" The latter is how I read it must be implemented -- and reading Microsoft's implementation and the reason they're using SL *strongly* suggests they also have read it that way. There are very probably many others. The paragraph is very unclear at best, extremely dangerous at worst. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 09:20:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9THKf29028858; Tue, 29 Oct 2002 09:20:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9THKflB028857; Tue, 29 Oct 2002 09:20:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9THKb29028850 for ; Tue, 29 Oct 2002 09:20:37 -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 g9THKhMq019379 for ; Tue, 29 Oct 2002 09:20: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 kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10781 for ; Tue, 29 Oct 2002 10:20:37 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 09:20:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3D3@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAABO/TgAA5GlaAAGJ18IA== From: "Michel Py" To: "Bound, Jim" , "Margaret Wasserman" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9THKc29028851 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [For the record, Internet access for passengers is a completely separate system that does not connect to the plane's systems, and here's the reason why: Imagine a bunch of IETFers in a plane. We all have laptops. Give us an Ethernet link to the plane, someone will hack the plane just to pass time during a long flight. Sounds like suicide to me....] > Jim Bound wrote: > here is not reason at all why what you stated could not > be link-local addresses. I would argue if sensors do what > I hear they will do link-locals are fine and we do have > controls on that and they are not forwarded off the link. That's not the way it works. In the rather classic triple or quintuple system redundancy, each of the devices that can control something is on a separate bus (a separate subnet). But it might talk to the other two or four all the time, and they occasionally vote and might decide that one of the devices is out of whack, things like this. So, there are multiple links in case of cable failure or jabbering NIC or something, but they might talk to each other. Site-local. > The cockpit and intra-connections could be viewed as on link > easily. Access to the FAA or GPA Sat-Com would require global > (hmm maybe inter-planetary scope :--)) and as in my previous > mail those would be gateways to the sensors. But the plane itself would not be completely isolated either. Let's face it: directly or indirectly there is almost no network today that is not connected to the Internet not even a plane in flight. So saying that SLs can not be used in networks that are connected to the Internet is the equivalent of killing them. Same as the other examples I used before: sensors/control devices in a metropolitan water distribution system, or in a power grid. SLs are a perfect choice for these, and somewhere in that network there will likely be a host that has access to the Internet as well. These topics have been discussed years ago, and I question why we need to revisit this. 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 Oct 29 09:45:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9THj429029002; Tue, 29 Oct 2002 09:45:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9THj4Ge029001; Tue, 29 Oct 2002 09:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9THj029028994 for ; Tue, 29 Oct 2002 09:45:01 -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 g9THj9Mq026945 for ; Tue, 29 Oct 2002 09:45:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09360 for ; Tue, 29 Oct 2002 10:44:59 -0700 (MST) Message-ID: <00a501c27f72$125fc220$656015ac@T23KEMPF> From: "James Kempf" To: "Bound, Jim" , "Thomas Narten" Cc: References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B63B@tayexc13.americas.cpqcorp.net> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 09:39:00 -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 Hi Jim, I hear your concerns quite clearly. One possibility would be to make the FastRA and Optimistic DAD work specific to MIPv6 wireless access routers, and therefore not a general IPv6 router enhancement. I think this would address your concern about impacting current wired router product plans. It really is only for mobility, as a wired host rarely to never changes its link. That would move the work to the MIP group, as a separate but complementary item to the current FMIPv6 work. The optimized MIPv6 work is still not quite ready for prime time, but it is getting there. Of course, this would require approval of the ADs, MIP WG chairs, and MIP WG. How does that sound? jak ----- Original Message ----- From: "Bound, Jim" To: "James Kempf" ; "Thomas Narten" Cc: Sent: Tuesday, October 29, 2002 7:39 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > James, > > ........................................Determination of > how this router is designated is outside the scope of this > document. An RA that is immediately unicast to the sender rather > than delayed is known as a "fast RA". > > I do not believe it should be outside the scope of this draft. I think > it imperative that this be defined clearly and a method proposed before > FAST RA can be bought into by IPv6 implementors. > > I also believe at this time the IESG should require a fairly good set of > reports from multiple implementations of this and other proposals for > wireless efforts that want to change DAD parameters and extend > attributes to ND and Stateless Addrconf. Right now the only work within > this space that has received the test of fire at UNH, ETSI, or TAHI as > examples is MIPv6. These tests beat hard on IPv6 implementation > enhancements as was just done for MIPv6 D-18 in Sophia Antipolis at > ETSI. I would suggest to the IESG doing any changes to ND or Addrconf > without serious hard core testing from this work is dangerous. > > If you, I, and others believe this is important then the code will get > done for this and Optimistic DAD and show up at the tests. Otherwise > this is purely a research and at best AD exercise. IPv6 is now being > deployed we cannot mess with DAD or Addr Conf in casual ways any more > than we do with IP (for v4), TCP, or RTT algrorithm for TCP as examples. > > I also believe all these efforts should begin to think like MIPv6 has > and that is they are separate documents and I strongly am against any > enhancments to ND or Addrconf from Fast RA, Optimistic DAD etc. They > should be new RFCs. > > All this also presents new security problems too that does not exist in > current ND and Addrconf on wired links. The base reason is that these > mess with the ND architecture and wired links that are firewalled or PKI > protected are more insulated than say 802.11b. > That being said I would like to see all security sections for this work > define what new security problems exist simply because of this behavior > not just say exists now in DAD or whatever. > > None of these options should be permitted for wire links (status quo) at > all. > That gives me an idea at least how the router to do Fast RA should be > defined. > > I would also like to see hard core router or switch "PRODUCT" developers > comment on this work and other work. I know routing code but not like > those that build ASICs and the like. > I would like to hear them say the pain and gain they feel or see from > this strategy. > > /jim > [Have you ever seen the rain coming down on a sunny day] > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 10:02:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TI2S29029205; Tue, 29 Oct 2002 10:02:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TI2S5Y029204; Tue, 29 Oct 2002 10:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TI2O29029197 for ; Tue, 29 Oct 2002 10:02:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TI2XMq003442 for ; Tue, 29 Oct 2002 10:02:33 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20922 for ; Tue, 29 Oct 2002 10:02:27 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TI2G027587; Tue, 29 Oct 2002 13:02:16 -0500 (EST) Message-Id: <200210291802.g9TI2G027587@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Bound, Jim" , "Margaret Wasserman" , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 09:20:42 PST.") <2B81403386729140A3A899A8B39B046405E3D3@server2000> Date: Tue, 29 Oct 2002 13:02:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Jim Bound wrote: > > here is not reason at all why what you stated could not > > be link-local addresses. I would argue if sensors do what > > I hear they will do link-locals are fine and we do have > > controls on that and they are not forwarded off the link. > > That's not the way it works. In the rather classic triple or quintuple > system redundancy, each of the devices that can control something is on > a separate bus (a separate subnet). But it might talk to the other two > or four all the time, and they occasionally vote and might decide that > one of the devices is out of whack, things like this. So, there are > multiple links in case of cable failure or jabbering NIC or something, > but they might talk to each other. Site-local. doesn't follow. you haven't made a case for site-local, you've just included the word at the end of the paragraph. > But the plane itself would not be completely isolated either. Let's face > it: directly or indirectly there is almost no network today that is not > connected to the Internet not even a plane in flight. So saying that SLs > can not be used in networks that are connected to the Internet is the > equivalent of killing them. killing SLs would not be a crime ... IMHO it would be a good thing, though I don't expect that to happen. ("it was a mercy killing, honest!") and the proposal I made was saying that they could not be used in networks that were connected to the Internet using IP. connection via ALGs would be acceptable. the point is that you don't expose a mixture of SLs and globals except to special-purpose apps like ALGs. (now if we can only figure out a way to make that stick this time) > Same as the other examples I used before: sensors/control devices in a > metropolitan water distribution system, or in a power grid. SLs are a > perfect choice for these, no they're not. because often the reason you want these sensors on IP in the first place is so that you don't have to provide your own infrastructure to talk to them at a distance. > These topics have been discussed years ago, and I question why we need > to revisit this. because in all this time nobody has figured out a sane way to actually use the things, even attempting to do so increases complexity without a significant gain, and they don't solve the problems they were supposed to solve. furthermore, appeals to past ignorance aren't exactly convincing. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 10:09:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TI9929029365; Tue, 29 Oct 2002 10:09:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TI990Y029364; Tue, 29 Oct 2002 10:09:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TI9429029348 for ; Tue, 29 Oct 2002 10:09:04 -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 g9TI9DMq005978 for ; Tue, 29 Oct 2002 10:09:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23328 for ; Tue, 29 Oct 2002 11:09:08 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TI8vKV020271; Tue, 29 Oct 2002 19:08:57 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 19:08:57 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C1C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Bound, Jim" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 19:08:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I hear your concerns quite clearly. > > One possibility would be to make the FastRA and Optimistic > DAD work specific to > MIPv6 wireless access routers, and therefore not a general > IPv6 router > enhancement. => The problem is there is no such thing as wireless access routers being bound to MIPv6 optimisations. The routers we have in IETF meetings are wireless, but there is no IP mobility going on. I think Jim's concerns (not you the other Jim :) ) can be handled because Fast RA and optimistic DAD do not change anything on the wire. In fact, Fast RAs have no impact on hosts at all. I agree with Jim Bound that you should mention how the designated router is known, but this can be done by manual config as a default mechanism. Optimistic DAD needs to be analysed carefully to make sure that the failure cases are rare and do not justify killing optimistic DAD. I think this analysus is ongoing. Hesham I think this would address your concern about > impacting current > wired router product plans. It really is only for mobility, > as a wired host > rarely to never changes its link. > > That would move the work to the MIP group, as a separate > but complementary item > to the current FMIPv6 work. The optimized MIPv6 work is > still not quite ready > for prime time, but it is getting there. Of course, this > would require approval > of the ADs, MIP WG chairs, and MIP WG. > > How does that sound? > > jak > > ----- Original Message ----- > From: "Bound, Jim" > To: "James Kempf" ; "Thomas Narten" > > Cc: > Sent: Tuesday, October 29, 2002 7:39 AM > Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > > James, > > > > ........................................Determination of > > how this router is designated is outside the scope of this > > document. An RA that is immediately unicast to the > sender rather > > than delayed is known as a "fast RA". > > > > I do not believe it should be outside the scope of this > draft. I think > > it imperative that this be defined clearly and a method > proposed before > > FAST RA can be bought into by IPv6 implementors. > > > > I also believe at this time the IESG should require a > fairly good set of > > reports from multiple implementations of this and other > proposals for > > wireless efforts that want to change DAD parameters and extend > > attributes to ND and Stateless Addrconf. Right now the > only work within > > this space that has received the test of fire at UNH, > ETSI, or TAHI as > > examples is MIPv6. These tests beat hard on IPv6 implementation > > enhancements as was just done for MIPv6 D-18 in Sophia > Antipolis at > > ETSI. I would suggest to the IESG doing any changes to > ND or Addrconf > > without serious hard core testing from this work is dangerous. > > > > If you, I, and others believe this is important then the > code will get > > done for this and Optimistic DAD and show up at the > tests. Otherwise > > this is purely a research and at best AD exercise. IPv6 > is now being > > deployed we cannot mess with DAD or Addr Conf in casual > ways any more > > than we do with IP (for v4), TCP, or RTT algrorithm for > TCP as examples. > > > > I also believe all these efforts should begin to think > like MIPv6 has > > and that is they are separate documents and I strongly am > against any > > enhancments to ND or Addrconf from Fast RA, Optimistic > DAD etc. They > > should be new RFCs. > > > > All this also presents new security problems too that > does not exist in > > current ND and Addrconf on wired links. The base reason > is that these > > mess with the ND architecture and wired links that are > firewalled or PKI > > protected are more insulated than say 802.11b. > > That being said I would like to see all security sections > for this work > > define what new security problems exist simply because of > this behavior > > not just say exists now in DAD or whatever. > > > > None of these options should be permitted for wire links > (status quo) at > > all. > > That gives me an idea at least how the router to do Fast > RA should be > > defined. > > > > I would also like to see hard core router or switch > "PRODUCT" developers > > comment on this work and other work. I know routing code > but not like > > those that build ASICs and the like. > > I would like to hear them say the pain and gain they feel > or see from > > this strategy. > > > > /jim > > [Have you ever seen the rain coming down on a sunny day] > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 29 10:18:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TIIc29029500; Tue, 29 Oct 2002 10:18:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TIIcHu029499; Tue, 29 Oct 2002 10:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TIIZ29029492 for ; Tue, 29 Oct 2002 10:18:35 -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 g9TIIjbB003624 for ; Tue, 29 Oct 2002 10:18:45 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12243 for ; Tue, 29 Oct 2002 10:18:39 -0800 (PST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9TIIVup022492; Tue, 29 Oct 2002 13:18:31 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 29 Oct 2002 13:18:15 -0500 Message-ID: <3DBED1D9.6020200@nc.rr.com> Date: Tue, 29 Oct 2002 13:22:17 -0500 From: Brian Haberman Organization: No Organization Here 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: Pekka Savola CC: ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Tue, 29 Oct 2002, Brian Haberman wrote: > >>>Note that KAME only supports this through manual configuration (and a >>>fix) -- clarified in off-the-list discussion. >>> >>>To be compliant with the paragraph: >>> >>> Routers must not forward any packets with site-local source or >>> destination addresses outside of the site. >>> >>>Note: it does not say 'packets from the site' (implying configuration of >>>the site) but 'with site-local source'. That strongly implies explicit >>>configuration will not satisfy. >> >>I don't read it that way at all. I interpret that to mean, if the >>router is configured as a site-border router it must not forward those >>packets out of the site. > > > That kind of interpretation is easy (== activation logic in the > implementation is simple) , but really, totally useless I believe. That depends on the model you believe. If we take Margaret's proposal that, by default, a node is in one site (you treat SLs as globals) then explicit config is needed to have a border router. In this scenario, the site-local zone ids are all the same. The other case is where each interface is in different site (that makes SLs equivalent to link-locals) and the site-local zone ids are all unique. > > The promise of using site-locals is that they will not propagate globally. > > Routers must make sure they don't do that, even without being configured > as site-border routers. That would require routers to always act as a site border router. > > If this wasn't true, nobody should be able to use site-locals even without > relatively clean conscience, as nobody could be sure there _is_ a router > that's blocking illegally-sourced site-locals from coming to my site or > vice versa. > > The paragraph requires clarification for sure. How about removing it? > > >>The behavior is as defined in Section 5 of the scoped addr arch which >>is all interfaces are in the same site, unless explicitly configured >>by an administrator. > > > Scoped arch draft is irrelevant from the perspective of addrarch > (independence) IMO. What I meant is that any discussion similar to that paragraph should be in the scoped addr arch. > > >>>1) node just blindly configures fec0::1 and starts sending traffic using >>>it, testing how far it will go. >>> >>>A valid scenario here could be that site-locals would be used inside one >>>link only -- no config at all in the router -- but the route must disallow >>>propagation of site-locals through default route if something fails. >> >>That does not follow from the discussion in scoped addr arch. Of >>course, this should be clarified in addr arch when we decide on the >>SL content of that document. > > > Better: _addrarch_ shouldn't say anything at all like that because we > don't know how to do it (or can't write it down). Agreed. > > >>>You may ask: how is this possible? we don't have any site-border >>>discovery mechanisms? >>> >>>I say: exactly, that's why the paragraph is so ridiculous! >>> >>>The only easy and compliant implementation I could think of would be >>>discarding all site-locals unless some links are explicitly configured to >>>be part of a site. >> >> From the discussion I have read, it seems that it would be more that >>we are assuming that all interfaces are in the same site unless >>explicitly configured. > > > The risk of site-local leakage is _way_ too big that way. My statement is based on the proposal that site-locals be restricted to disconnected networks. 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 Oct 29 11:38:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TJc929000160; Tue, 29 Oct 2002 11:38:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TJc9uS000159; Tue, 29 Oct 2002 11:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TJc629000150 for ; Tue, 29 Oct 2002 11:38: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 g9TJcFbB000033 for ; Tue, 29 Oct 2002 11:38:15 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00299 for ; Tue, 29 Oct 2002 11:38:09 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 29 Oct 2002 11:37:50 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 11:37:29 -0800 Message-ID: <06b401c27f82$9eabcb10$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9774@tayexc13.americas.cpqcorp.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TJc629000151 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: > So if I read your view. Your saying. Control them but do > not revoke them? > > The question is can we control them then right? > I was trying to say; comment on known problem areas, but nothing more. This is because we can't control their use, and even if we could, we might be cutting of a valuable service down the road. When we know there is a problem, like the use of SL with the current single scope DNS servers, we should point out the reasons developers should think twice before going there. > But if we can't figure it out or agree then that could be revoke? No. There are deployment models where SL is what the network manager wants, but those who are complaining on this list are not working in networks with those models. Before any discussion about removing them can take place, the people that want to use them need a voice. Tony > > I would hope we can control and not revoke. > > But as you know I don't believe they should have ever been > permitted in the first place in IPv6. Site-Locals and 1918 > are BOGUS that is not how to control what they wanted to do > in the first place. > > /jim > [Have you ever seen the rain coming down on a sunny day] > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Monday, October 28, 2002 2:47 PM > > To: ipng@sunroof.eng.sun.com > > Subject: RE: Limiting the Use of Site-Local > > > > > > I have a basic problem with this thread. We have a few people > > discussing fundamental changes in close to a vacuum. At best > > the result of this discussion should be a separate BCP, but > > before that happens operators of networks that actually use > > 1918 space need to be engaged to find out their requirements. > > > > The whole idea that SL should be revoked if a global is > > available is bogus. It is certainly reasonable for the > > manufacturer of light switches to only support SL/LL rather > > than potentially multiple global prefixes. There is no reason > > for those devices to interact across a scope boundary, so the > > peer nodes that may also need global access MUST keep their > > SL to interact in the limited scope. > > > > Tony > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 11:59:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TJx029000401; Tue, 29 Oct 2002 11:59:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TJwxMU000398; Tue, 29 Oct 2002 11:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TJwt29000391 for ; Tue, 29 Oct 2002 11:58: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 g9TJx5Mq015181 for ; Tue, 29 Oct 2002 11:59:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13733 for ; Tue, 29 Oct 2002 11:58:59 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TJwp027993; Tue, 29 Oct 2002 14:58:51 -0500 (EST) Message-Id: <200210291958.g9TJwp027993@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Bound, Jim'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 11:37:29 PST.") <06b401c27f82$9eabcb10$4b194104@eagleswings> Date: Tue, 29 Oct 2002 14:58:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I was trying to say; comment on known problem areas, but nothing more. > This is because we can't control their use, and even if we could, we > might be cutting of a valuable service down the road. _inclusion_ of SL might be cutting off a valuable service down the road, and we have far more reason to believe that inclusion will cut off functionality than we have to believe that it will provide additional functionality. > When we know there is a problem, like the use of SL with the > current single scope DNS servers, we should point out the > reasons developers should think twice before going there. we know of *lots* of problems with SL. shouldn't we think twice about going there? > No. There are deployment models where SL is what the network manager > wants, only because they either misunderstand what SL will do or because they think they can't get globals. there's no reason whatsoever to prefer SL to non-routable globals. > but those who are complaining on this list are not working in > networks with those models. wrong - it's precisely because some of us have had to work in networks with similar models that we are so sensitive to SL brain-damage. > Before any discussion about removing them > can take place, the people that want to use them need a voice. how about people who write apps? do they need a voice also? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 12:11:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKBi29000681; Tue, 29 Oct 2002 12:11:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKBihi000680; Tue, 29 Oct 2002 12:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKBf29000671 for ; Tue, 29 Oct 2002 12:11:41 -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 g9TKBoMq019774 for ; Tue, 29 Oct 2002 12:11:50 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21981 for ; Tue, 29 Oct 2002 12:11:45 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 29 Oct 2002 12:11:45 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , Cc: "'Alain Durand'" , "'Michel Py'" , Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 12:11:24 -0800 Message-ID: <06b801c27f87$5d253ff0$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210291410.g9TEAk025423@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKBf29000672 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... in other words, we need to abandon this idea > that a host can have an arbitrary number of addresses with > varying scopes and lifetimes and connectivity, > and it's up to hosts/apps to sort out which one is best to > use. ... We have heard you say this many times over, but you are refusing to hear that other people have figured out how to use them for their specific app or topology. Since you have identified the case that a multi-party app can't do the right thing when the name/address resolution is only capable of a single scope, you should write a BCP to that effect. Otherwise your argument ammounts to a demand that we not allow doing more than what we always have done, simply because it is easier. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 12:17:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKHd29000822; Tue, 29 Oct 2002 12:17:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKHc7L000821; Tue, 29 Oct 2002 12:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKHY29000813 for ; Tue, 29 Oct 2002 12:17: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 g9TKHhbB012782 for ; Tue, 29 Oct 2002 12:17:43 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25259 for ; Tue, 29 Oct 2002 12:17:38 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 12:17:37 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 12:17:37 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 12:17:36 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 12:17:36 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/Vahtg4Xo/U1OSVazDhFGO+13WgAMRqzQ From: "Brian Zill" To: "Keith Moore" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 29 Oct 2002 20:17:36.0707 (UTC) FILETIME=[38EC1130:01C27F88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKHY29000815 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore writes: > >> Brian Zill writes: >> One advantage of having scoped addresses defined >> in the IPv6 architecture from the start is that >> applications can know not to pass them outside >> of their scope. > > NO. > > 1. applications don't know where their scope ends. They don't need to. If they are communicating with another entity via a site-local address, then that entity is by definition within scope. Therefore they can legitimately pass a site-local address in the data stream to that entity. Otherwise, they can't. Very simple and straight-forward. > 2. expecting applications to know about network > topology drastically increases their complexity > without any recognizable benefits. As noted above, the applications don't need to know anything about the network topology, they only need to know what kind of addresses they are using. If, however, random global address which happened not to be globally routable (due to firewalls/filters) were used, the app couldn't determine this, and could end up blindly passing these non-routable addresses around in the data stream. Using site-local addresses solves this problem. --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 Oct 29 12:23:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKNH29001023; Tue, 29 Oct 2002 12:23:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKNHbv001022; Tue, 29 Oct 2002 12:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKND29001015 for ; Tue, 29 Oct 2002 12:23:14 -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 g9TKNNMq023311 for ; Tue, 29 Oct 2002 12:23:23 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25355 for ; Tue, 29 Oct 2002 13:23:17 -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 D417CB1C; Tue, 29 Oct 2002 15:23:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 15:23:16 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 15:23:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97A1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAABO/TgAA5GlaAAGJ18IAAHFN6g From: "Bound, Jim" To: "Michel Py" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 29 Oct 2002 20:23:16.0747 (UTC) FILETIME=[039A0DB0:01C27F89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKNE29001016 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I simply have completely different data but will go check with friends at Boeing and be back. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Tuesday, October 29, 2002 12:21 PM > To: Bound, Jim; Margaret Wasserman; alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > [For the record, Internet access for passengers is a > completely separate system that does not connect to the > plane's systems, and here's the reason why: Imagine a bunch > of IETFers in a plane. We all have laptops. Give us an > Ethernet link to the plane, someone will hack the plane just > to pass time during a long flight. Sounds like suicide to me....] > > > Jim Bound wrote: > > here is not reason at all why what you stated could not > > be link-local addresses. I would argue if sensors do what > > I hear they will do link-locals are fine and we do have controls on > > that and they are not forwarded off the link. > > That's not the way it works. In the rather classic triple or > quintuple system redundancy, each of the devices that can > control something is on a separate bus (a separate subnet). > But it might talk to the other two or four all the time, and > they occasionally vote and might decide that one of the > devices is out of whack, things like this. So, there are > multiple links in case of cable failure or jabbering NIC or > something, but they might talk to each other. Site-local. > > > The cockpit and intra-connections could be viewed as on > link easily. > > Access to the FAA or GPA Sat-Com would require global (hmm maybe > > inter-planetary scope :--)) and as in my previous mail > those would be > > gateways to the sensors. > > But the plane itself would not be completely isolated either. > Let's face > it: directly or indirectly there is almost no network today > that is not connected to the Internet not even a plane in > flight. So saying that SLs can not be used in networks that > are connected to the Internet is the equivalent of killing them. > > Same as the other examples I used before: sensors/control > devices in a metropolitan water distribution system, or in a > power grid. SLs are a perfect choice for these, and somewhere > in that network there will likely be a host that has access > to the Internet as well. > > These topics have been discussed years ago, and I question > why we need to revisit this. > > 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 Oct 29 12:26:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKQe29001139; Tue, 29 Oct 2002 12:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKQewW001138; Tue, 29 Oct 2002 12:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKQa29001131 for ; Tue, 29 Oct 2002 12:26:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TKQjbB015646 for ; Tue, 29 Oct 2002 12:26:45 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27267 for ; Tue, 29 Oct 2002 13:26:39 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TKOV028083; Tue, 29 Oct 2002 15:24:31 -0500 (EST) Message-Id: <200210292024.g9TKOV028083@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , Mark.Andrews@isc.org, "'Alain Durand'" , "'Michel Py'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 12:11:24 PST.") <06b801c27f87$5d253ff0$4b194104@eagleswings> Date: Tue, 29 Oct 2002 15:24:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... in other words, we need to abandon this idea > > that a host can have an arbitrary number of addresses with > > varying scopes and lifetimes and connectivity, > > and it's up to hosts/apps to sort out which one is best to > > use. ... > > We have heard you say this many times over, but you are refusing to hear > that other people have figured out how to use them for their specific > app or topology. Just because some apps happen to work with SLs or are easily modified to work with SLs does not mean that SLs are either harmless or justified. > Since you have identified the case that a multi-party > app can't do the right thing when the name/address resolution is only > capable of a single scope, you should write a BCP to that effect. I have no interest in describing how to impair apps to deal with an impaired network. I find it far saner, and hopefully more productive, to keep the network from being impaired in the first place. > Otherwise your argument ammounts to a demand that we not allow doing > more than what we always have done, simply because it is easier. No, I'm arguing for a more flexible Internet, one that can support a wider range of applications with less complexity. more warts does not equate to more flexibility, and SL is a good example of a wart that decreases flexibility. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 12:28:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKSI29001214; Tue, 29 Oct 2002 12:28:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKSICC001212; Tue, 29 Oct 2002 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKSE29001203 for ; Tue, 29 Oct 2002 12:28:14 -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 g9TKSNMq028867 for ; Tue, 29 Oct 2002 12:28:23 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28403 for ; Tue, 29 Oct 2002 13:28:17 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F0C274085; Tue, 29 Oct 2002 15:28:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 15:27:57 -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: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 15:27:57 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97A3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing RS Reply Timing for Mobile IPv6 Thread-Index: AcJ/clQ7LH5E+12QTmG0WW+TYdNJDAAFvDDg From: "Bound, Jim" To: "James Kempf" , "Thomas Narten" Cc: X-OriginalArrivalTime: 29 Oct 2002 20:27:57.0603 (UTC) FILETIME=[AB014730:01C27F89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKSE29001204 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, Amazing Brian Haley and I were just talking this a.m. as this concerns our worrk to. We like what you and Optimistic DAD propose but we also are responsible for these "wired" boxes. That is what we concluded too. We can't see a case where an 802.11b AP is just another interface to a wired-link but will be its own link. So I think that is a good idea. And will avoid the entire problem I sent and to Nick privately on the Optimistic DAD (which I think adds great value to the FastRA reqs too). thanks /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, October 29, 2002 12:39 PM > To: Bound, Jim; Thomas Narten > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > Hi Jim, > > I hear your concerns quite clearly. > > One possibility would be to make the FastRA and Optimistic > DAD work specific to MIPv6 wireless access routers, and > therefore not a general IPv6 router enhancement. I think this > would address your concern about impacting current wired > router product plans. It really is only for mobility, as a > wired host rarely to never changes its link. > > That would move the work to the MIP group, as a separate but > complementary item to the current FMIPv6 work. The optimized > MIPv6 work is still not quite ready for prime time, but it is > getting there. Of course, this would require approval of the > ADs, MIP WG chairs, and MIP WG. > > How does that sound? > > jak > > ----- Original Message ----- > From: "Bound, Jim" > To: "James Kempf" ; "Thomas Narten" > > Cc: > Sent: Tuesday, October 29, 2002 7:39 AM > Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > > James, > > > > ........................................Determination of > > how this router is designated is outside the scope of this > > document. An RA that is immediately unicast to the sender rather > > than delayed is known as a "fast RA". > > > > I do not believe it should be outside the scope of this draft. I > > think it imperative that this be defined clearly and a > method proposed > > before FAST RA can be bought into by IPv6 implementors. > > > > I also believe at this time the IESG should require a > fairly good set > > of reports from multiple implementations of this and other > proposals > > for wireless efforts that want to change DAD parameters and extend > > attributes to ND and Stateless Addrconf. Right now the only work > > within this space that has received the test of fire at > UNH, ETSI, or > > TAHI as examples is MIPv6. These tests beat hard on IPv6 > > implementation enhancements as was just done for MIPv6 D-18 > in Sophia > > Antipolis at ETSI. I would suggest to the IESG doing any > changes to > > ND or Addrconf without serious hard core testing from this work is > > dangerous. > > > > If you, I, and others believe this is important then the > code will get > > done for this and Optimistic DAD and show up at the tests. > Otherwise > > this is purely a research and at best AD exercise. IPv6 is > now being > > deployed we cannot mess with DAD or Addr Conf in casual > ways any more > > than we do with IP (for v4), TCP, or RTT algrorithm for TCP as > > examples. > > > > I also believe all these efforts should begin to think like > MIPv6 has > > and that is they are separate documents and I strongly am > against any > > enhancments to ND or Addrconf from Fast RA, Optimistic DAD > etc. They > > should be new RFCs. > > > > All this also presents new security problems too that does > not exist > > in current ND and Addrconf on wired links. The base reason is that > > these mess with the ND architecture and wired links that are > > firewalled or PKI protected are more insulated than say > 802.11b. That > > being said I would like to see all security sections for this work > > define what new security problems exist simply because of this > > behavior not just say exists now in DAD or whatever. > > > > None of these options should be permitted for wire links > (status quo) > > at all. That gives me an idea at least how the router to do Fast RA > > should be defined. > > > > I would also like to see hard core router or switch "PRODUCT" > > developers comment on this work and other work. I know > routing code > > but not like those that build ASICs and the like. I would > like to hear > > them say the pain and gain they feel or see from this strategy. > > > > /jim > > [Have you ever seen the rain coming down on a sunny day] > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 12:32:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKWM29001323; Tue, 29 Oct 2002 12:32:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKWLa9001322; Tue, 29 Oct 2002 12:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKWH29001315 for ; Tue, 29 Oct 2002 12:32:17 -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 g9TKWQMq000401 for ; Tue, 29 Oct 2002 12:32:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16612 for ; Tue, 29 Oct 2002 12:32:21 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TKWF028105; Tue, 29 Oct 2002 15:32:15 -0500 (EST) Message-Id: <200210292032.g9TKWF028105@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 12:17:36 PST.") Date: Tue, 29 Oct 2002 15:32:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Brian Zill writes: > >> One advantage of having scoped addresses defined > >> in the IPv6 architecture from the start is that > >> applications can know not to pass them outside > >> of their scope. > > > > NO. > > > > 1. applications don't know where their scope ends. > > They don't need to. If they are communicating with another entity via a > site-local address, then that entity is by definition within scope. that doesn't mean that the entity that will end up using the address is within scope. where do you get the idea that all referrals are one hop? furthermore it's wrong (or at least incomplete) because a host can have access to multiple scopes. > Therefore they can legitimately pass a site-local address in the data > stream to that entity. Otherwise, they can't. Very simple and > straight-forward. it's simple, straight-forward -- and incorrect. > > 2. expecting applications to know about network > > topology drastically increases their complexity > > without any recognizable benefits. > > As noted above, the applications don't need to know anything about the > network topology, they only need to know what kind of addresses they are > using. False. there's no way that a referrer can know what scopes the party to which the addresses are being referred has access to. the best the referrer can do is refer all available addresses. even then, without global scope IDs we don't have a way for the party using those referrals to know which addresses are valid in the scopes to which it has access. > If, however, random global address which happened not to be > globally routable (due to firewalls/filters) were used, the app couldn't > determine this, and could end up blindly passing these non-routable > addresses around in the data stream. yes, but since the addresses are global the party that is *using* the addresses has at least some chance of knowing whether it has access to them. (for instance, does it have a route to that net?) more importantly, if you get rid of SLs there's far less need to pass so many addresses around, so the chance that either (a) the address will work or (b) the situation is beyond reasonable ability of an app to fix, is far greater. > Using site-local addresses solves this problem. no, it exacerbates the problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 12:44:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKib29001706; Tue, 29 Oct 2002 12:44:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKib5T001705; Tue, 29 Oct 2002 12:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKiY29001698 for ; Tue, 29 Oct 2002 12:44:34 -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 g9TKihbB021389 for ; Tue, 29 Oct 2002 12:44:43 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19333 for ; Tue, 29 Oct 2002 13:44:37 -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 DB2528A4; Tue, 29 Oct 2002 15:44:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Oct 2002 15:44:36 -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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 15:44:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97A6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/grvYXjlrv2cBS3qcqfX93Blc8gACTCFA From: "Bound, Jim" To: , X-OriginalArrivalTime: 29 Oct 2002 20:44:36.0767 (UTC) FILETIME=[FE8D9AF0:01C27F8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKiY29001699 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I support that. We do need to hear from the network managers I agree. But I do think we need controls pretty soon. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Tuesday, October 29, 2002 2:37 PM > To: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > Bound, Jim wrote: > > So if I read your view. Your saying. Control them but do > > not revoke them? > > > > The question is can we control them then right? > > > > I was trying to say; comment on known problem areas, but > nothing more. This is because we can't control their use, and > even if we could, we might be cutting of a valuable service > down the road. When we know there is a problem, like the use > of SL with the current single scope DNS servers, we should > point out the reasons developers should think twice before > going there. > > > But if we can't figure it out or agree then that could be revoke? > > No. There are deployment models where SL is what the network > manager wants, but those who are complaining on this list are > not working in networks with those models. Before any > discussion about removing them can take place, the people > that want to use them need a voice. > > Tony > > > > > I would hope we can control and not revoke. > > > > But as you know I don't believe they should have ever been > > permitted in the first place in IPv6. Site-Locals and 1918 > > are BOGUS that is not how to control what they wanted to do > > in the first place. > > > > /jim > > [Have you ever seen the rain coming down on a sunny day] > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Monday, October 28, 2002 2:47 PM > > > To: ipng@sunroof.eng.sun.com > > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > I have a basic problem with this thread. We have a few people > > > discussing fundamental changes in close to a vacuum. At best the > > > result of this discussion should be a separate BCP, but > before that > > > happens operators of networks that actually use 1918 > space need to > > > be engaged to find out their requirements. > > > > > > The whole idea that SL should be revoked if a global is > available is > > > bogus. It is certainly reasonable for the manufacturer of light > > > switches to only support SL/LL rather than potentially multiple > > > global prefixes. There is no reason for those devices to interact > > > across a scope boundary, so the peer nodes that may also > need global > > > access MUST keep their SL to interact in the limited scope. > > > > > > Tony > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 12:59:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKxp29002118; Tue, 29 Oct 2002 12:59:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TKxoDS002117; Tue, 29 Oct 2002 12:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TKxl29002110 for ; Tue, 29 Oct 2002 12:59:47 -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 g9TKxtbB026352 for ; Tue, 29 Oct 2002 12:59:56 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17756 for ; Tue, 29 Oct 2002 13:59:50 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 12:59:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD277@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ+zBbCli5UbT1BQD69IoFIX9IhEAABO/TgAA5GlaAAGJ18IAAHFN6gAAFJZtA= From: "Michel Py" To: "Bound, Jim" , "Margaret Wasserman" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TKxl29002111 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Boeing is not the only aircraft manufacturer in the world.... -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Tuesday, October 29, 2002 12:23 PM To: Michel Py; Margaret Wasserman; alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local I simply have completely different data but will go check with friends at Boeing and be back. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Tuesday, October 29, 2002 12:21 PM > To: Bound, Jim; Margaret Wasserman; alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > [For the record, Internet access for passengers is a > completely separate system that does not connect to the > plane's systems, and here's the reason why: Imagine a bunch > of IETFers in a plane. We all have laptops. Give us an > Ethernet link to the plane, someone will hack the plane just > to pass time during a long flight. Sounds like suicide to me....] > > > Jim Bound wrote: > > here is not reason at all why what you stated could not > > be link-local addresses. I would argue if sensors do what > > I hear they will do link-locals are fine and we do have controls on > > that and they are not forwarded off the link. > > That's not the way it works. In the rather classic triple or > quintuple system redundancy, each of the devices that can > control something is on a separate bus (a separate subnet). > But it might talk to the other two or four all the time, and > they occasionally vote and might decide that one of the > devices is out of whack, things like this. So, there are > multiple links in case of cable failure or jabbering NIC or > something, but they might talk to each other. Site-local. > > > The cockpit and intra-connections could be viewed as on > link easily. > > Access to the FAA or GPA Sat-Com would require global (hmm maybe > > inter-planetary scope :--)) and as in my previous mail > those would be > > gateways to the sensors. > > But the plane itself would not be completely isolated either. > Let's face > it: directly or indirectly there is almost no network today > that is not connected to the Internet not even a plane in > flight. So saying that SLs can not be used in networks that > are connected to the Internet is the equivalent of killing them. > > Same as the other examples I used before: sensors/control > devices in a metropolitan water distribution system, or in a > power grid. SLs are a perfect choice for these, and somewhere > in that network there will likely be a host that has access > to the Internet as well. > > These topics have been discussed years ago, and I question > why we need to revisit this. > > 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 Oct 29 13:15:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLF129002335; Tue, 29 Oct 2002 13:15:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLF1G9002334; Tue, 29 Oct 2002 13:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLEw29002327 for ; Tue, 29 Oct 2002 13:14: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 g9TLF7Mq013035 for ; Tue, 29 Oct 2002 13:15:07 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16302 for ; Tue, 29 Oct 2002 14:15:00 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TLErQ1026868; Tue, 29 Oct 2002 22:14:53 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 22:14:53 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C25@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Bound, Jim" Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 22:14:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > There is, however, a potential risk to using > site-local addresses > for long-lived connections. Those connections may > fail when a site > becomes partitioned, even if global connectivity is > still available > between the partitions. => FWIW, I think that one can see this as an advantage. An admin might not want these connections to survive when going through the Internet (outside the site). When the site was partitioned, an admin could have forgotten about these connections (?) and using site-local helped made this obvious. As opposed to having (potentially) sensitive data going over the public net. Just another way of thinking about this... Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 13:18:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLIr29002415; Tue, 29 Oct 2002 13:18:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLIrDf002414; Tue, 29 Oct 2002 13:18:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLIo29002407 for ; Tue, 29 Oct 2002 13:18:50 -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 g9TLIxbB002277 for ; Tue, 29 Oct 2002 13:18:59 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12854 for ; Tue, 29 Oct 2002 14:18:53 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 13:18:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3D5@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/dX9dFzYt+6qrSTGA9WxvgJvNAAAGVdjQ From: "Michel Py" To: "Keith Moore" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TLIo29002408 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> Same as the other examples I used before: sensors/control >> devices in a metropolitan water distribution system, or >> in a power grid. SLs are a perfect choice for these, > Keith Moore wrote: > no they're not. because often the reason you want these > sensors on IP in the first place is so that you don't have > to provide your own infrastructure to talk to them at a > distance. I have to use the same word as Richard did before: crazyness. Keith, what you are saying here is that the utility company is going to have to use PA addresses, that it does not own, to configure tens of thousands of devices on thousands of subnets, and be forced to renumber if they want to switch ISPs, even though these devices have nothing to do with the public Internet, just because you don't like SLs. No, no and no. 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 Oct 29 13:29:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLTL29002657; Tue, 29 Oct 2002 13:29:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLTKS5002652; Tue, 29 Oct 2002 13:29:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLTE29002638 for ; Tue, 29 Oct 2002 13:29:14 -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 g9TLTNMq017457 for ; Tue, 29 Oct 2002 13:29:23 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07744 for ; Tue, 29 Oct 2002 13:29:18 -0800 (PST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 13:29:17 -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, 29 Oct 2002 13:29:16 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 13:29:16 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 13:29:16 -0800 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: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 13:29:16 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/kJVYuG5znIOQSIOc6c4TUcFBiAAATCFg From: "Richard Draves" To: "Hesham Soliman (EAB)" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 29 Oct 2002 21:29:16.0051 (UTC) FILETIME=[3B87E630:01C27F92] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TLTE29002641 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > There is, however, a potential risk to using > > site-local addresses > > for long-lived connections. Those connections may > > fail when a site > > becomes partitioned, even if global connectivity is > > still available > > between the partitions. > > => FWIW, I think that one can see this as an advantage. > An admin might not want these connections to survive > when going through the Internet (outside the site). > When the site was partitioned, an admin could have forgotten > about these connections (?) and using site-local helped made > this obvious. As opposed to having (potentially) sensitive > data going over the public net. Yes of course that's an advantage. I can't imagine anyone (from enterprise network administrator to home user) wanting intra-site communication to suddenly be routed outside the site. 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 Tue Oct 29 13:34:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLYH29002786; Tue, 29 Oct 2002 13:34:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLYHCS002785; Tue, 29 Oct 2002 13:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLYD29002778 for ; Tue, 29 Oct 2002 13:34:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TLYMMq019184 for ; Tue, 29 Oct 2002 13:34:22 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09485 for ; Tue, 29 Oct 2002 14:34:17 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TLYB028461; Tue, 29 Oct 2002 16:34:11 -0500 (EST) Message-Id: <200210292134.g9TLYB028461@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 13:18:59 PST.") <2B81403386729140A3A899A8B39B046405E3D5@server2000> Date: Tue, 29 Oct 2002 16:34:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have to use the same word as Richard did before: crazyness. let's just say that there's a lot of craziness going around. > Keith, what you are saying here is that the utility company is going to > have to use PA addresses, that it does not own, to configure tens of > thousands of devices on thousands of subnets, and be forced to renumber > if they want to switch ISPs, even though these devices have nothing to > do with the public Internet, just because you don't like SLs. and what you are saying is that everybody who wants to network together large number of devices is going to create their own network infrastructure so they can use SL addresses (because dealing with globals is Just Too Onerous) -- and that everybody else on the Internet needs to be burdened with SLs just so they can do that. I don't buy that for a nanosecond. first, I don't buy that provider-based addresses are inherently that much of a burden. and it's far easier to solve the renumbering problem (particularly for special-purpose devices) than to solve the SL addressibility problem. second, I don't buy that we're stuck with provider-based addresses anyway. third, I don't buy that every company wants to set up its own infrastructure to network to remote devices when they can take bids from competing providers who already have infrastructure - or even use a mixture of providers. (for instance, you can combine wired, wireless, satellite depending on where your devices are) fourth, I don't buy that the existence of provider-based addresses is a compelling reason to burden us with SLs. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 13:36:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLaD29002833; Tue, 29 Oct 2002 13:36:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLaDWM002832; Tue, 29 Oct 2002 13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLa929002825 for ; Tue, 29 Oct 2002 13:36:10 -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 g9TLaJbB007628 for ; Tue, 29 Oct 2002 13:36:19 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12005 for ; Tue, 29 Oct 2002 13:36:14 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 13:36:13 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 13:36:13 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 29 Oct 2002 13:36:13 -0800 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: Forwarding packets with site-local source [Re: Choices to go forward with SL] Date: Tue, 29 Oct 2002 13:36:12 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Forwarding packets with site-local source [Re: Choices to go forward with SL] Thread-Index: AcJ/aUy9lghMfL27TAGLO9npoP0fjwAKOfnQ From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 29 Oct 2002 21:36:13.0441 (UTC) FILETIME=[34508F10:01C27F93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9TLaA29002826 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Some read it (many): > > "if I configure a site here, I must also block site-locals > from spreading > out or false site-locals coming in" > > Some others read it: > > "if I use site-locals here, my upstream router will block > the site-local > addresses from spreading out and prevent anyone from spoofing > site-locals > to my site" > > The latter is how I read it must be implemented -- and > reading Microsoft's implementation and the reason they're > using SL *strongly* suggests they > also have read it that way. There are very probably many others. No, I think you're the only person reading it the latter way. My expectation is that routers will need to be configured to understand site boundaries. A conservative position is that routers by default should regard their interfaces as belonging to different sites, unless they are configured to be in the same site. Or perhaps other aspects of the router's configuration (eg the network prefixes assigned to different interfaces, or the routing protocols in use) could be used to default the site configuration. 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 Tue Oct 29 13:43:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLhq29003164; Tue, 29 Oct 2002 13:43:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLhqRj003163; Tue, 29 Oct 2002 13:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLhm29003152 for ; Tue, 29 Oct 2002 13:43:48 -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 g9TLhubB009750 for ; Tue, 29 Oct 2002 13:43:57 -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 OAA15131 for ; Tue, 29 Oct 2002 14:43:42 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26866; Tue, 29 Oct 2002 16:41:17 -0500 (EST) Message-Id: <200210292141.QAA26866@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: IP Version 6 Addressing Architecture to Draft Standard Date: Tue, 29 Oct 2002 16:41:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Version 6 Addressing Architecture' as a Draft Standard. This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary This specification defines the addressing architecture of the IP Version 6 protocol (RFC 2460). The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. Working Group Summary The WG originally asked to advance this document to Draft standard in 1998, but the IESG pushed back on advancement pending more implementation experience on some aspects of multicast scoping and on concerns over the readiness of advancing the companion "Aggregatable Global Unicast Address Format" document with which it had been paired. Since that time, additional interoperability has been demonstrated, and the document is being advanced independent of the other document. There has been (and continues to be) continued support in the WG for advancement of this document. A new IETF Last Call was held in December, 2000. Comments and IESG discussion resulting from the 2nd Last Call resulted in a number of document changes. Those changes included: - removing the Format Prefix (to clarify that implementations should not build in knowledge about any prefixes except ones that are explicitly listed in the specification), - making it clear that all address space was to be treated as global unicast, except in those specific cases where other definitions already existed, - making it clear that reference to RFC 2374 (An Aggregatable Global Unicast Address Format) was an example, as address assignment policy is under the domain of the RIRs A full list of changes can be found in the changes section of the document. The document was then Last Called again, and no comments were raised at that time. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 13:46:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLk429003249; Tue, 29 Oct 2002 13:46:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLk4Hu003248; Tue, 29 Oct 2002 13:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLk029003241 for ; Tue, 29 Oct 2002 13:46:00 -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 g9TLk9bB010365 for ; Tue, 29 Oct 2002 13:46:09 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01019 for ; Tue, 29 Oct 2002 14:46:03 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TLjmQ1028890; Tue, 29 Oct 2002 22:45:48 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 22:45:48 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C27@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Richard Draves'" , Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: RE: Forwarding packets with site-local source [Re: Choices to go forward with SL] Date: Tue, 29 Oct 2002 22:45:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Some read it (many): > > > > "if I configure a site here, I must also block site-locals > > from spreading > > out or false site-locals coming in" > > > > Some others read it: > > > > "if I use site-locals here, my upstream router will block > > the site-local > > addresses from spreading out and prevent anyone from spoofing > > site-locals > > to my site" > > > > The latter is how I read it must be implemented -- and > > reading Microsoft's implementation and the reason they're > > using SL *strongly* suggests they > > also have read it that way. There are very probably many others. > > No, I think you're the only person reading it the latter way. => Agreed. I haven't seen anyone else interpret it this way. Hesham > > My expectation is that routers will need to be configured > to understand > site boundaries. A conservative position is that routers by default > should regard their interfaces as belonging to different > sites, unless > they are configured to be in the same site. Or perhaps > other aspects of > the router's configuration (eg the network prefixes assigned to > different interfaces, or the routing protocols in use) > could be used to > default the site configuration. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 13:53:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLrC29003441; Tue, 29 Oct 2002 13:53:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLrBeP003440; Tue, 29 Oct 2002 13:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLr729003428 for ; Tue, 29 Oct 2002 13:53:07 -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 g9TLrBbB012301 for ; Tue, 29 Oct 2002 13:53:11 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05680 for ; Tue, 29 Oct 2002 14:53:06 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TLr0028582; Tue, 29 Oct 2002 16:53:00 -0500 (EST) Message-Id: <200210292153.g9TLr0028582@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Hesham Soliman (EAB)" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 13:29:16 PST.") Date: Tue, 29 Oct 2002 16:53:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes of course that's an advantage. I can't imagine anyone (from > enterprise network administrator to home user) wanting intra-site > communication to suddenly be routed outside the site. nor can I. but why wouldn't simple filters on outgoing interfaces solve this? or to put it another way, why do you have so much faith in filters of SL addresses and so little faith in filters of prefixes? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 13:57:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLvC29003542; Tue, 29 Oct 2002 13:57:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TLvCmh003541; Tue, 29 Oct 2002 13:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TLv929003534 for ; Tue, 29 Oct 2002 13:57: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 g9TLvIMq026420 for ; Tue, 29 Oct 2002 13:57:18 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24372 for ; Tue, 29 Oct 2002 13:57:12 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TLv3KV011611; Tue, 29 Oct 2002 22:57:03 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 22:57:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C28@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" , Richard Draves Cc: "Hesham Soliman (EAB)" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Tue, 29 Oct 2002 22:57:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > or to put it another way, why do you have so much faith in > filters of SL addresses and so little faith in filters of prefixes? > => Because they're not configured, they're hardcoded. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 14:06:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TM6Q29003722; Tue, 29 Oct 2002 14:06:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TM6Q0F003721; Tue, 29 Oct 2002 14:06:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TM6M29003714 for ; Tue, 29 Oct 2002 14:06:22 -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 g9TM6VbB016392 for ; Tue, 29 Oct 2002 14:06:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00405 for ; Tue, 29 Oct 2002 14:06:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9TM6D028661; Tue, 29 Oct 2002 17:06:13 -0500 (EST) Message-Id: <200210292206.g9TM6D028661@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Keith Moore'" , Richard Draves , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 22:57:03 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C28@Esealnt861.al.sw.ericsson.se> Date: Tue, 29 Oct 2002 17:06:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > or to put it another way, why do you have so much faith in > > filters of SL addresses and so little faith in filters of prefixes? > > > > => Because they're not configured, they're hardcoded. on the contrary, SLs *are* configured. the same host platforms will use either SLs or globals or both - whether they use SL isn't hardcoded, it's a matter of configuration. the same hardware that routes SLs within a site will be used to block routing of SLs outside of a site - it's just a matter of configuration as to whether they're on a site border or not. in one case you tell the router to filter SLs, in another case you tell it to filter all addresses with certain prefixes. any device vendor that hardcodes a dependence on SL is drastically reducing its potential market. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 14:11:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TMBO29003803; Tue, 29 Oct 2002 14:11:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TMBOPg003802; Tue, 29 Oct 2002 14:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TMBK29003795 for ; Tue, 29 Oct 2002 14:11:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TMBTbB017941 for ; Tue, 29 Oct 2002 14:11:29 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01575 for ; Tue, 29 Oct 2002 15:11:24 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA00423; Tue, 29 Oct 2002 14:11:07 -0800 (PST) Message-Id: <5.1.0.14.2.20021029171016.07aeb4f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 17:11:40 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'Keith Moore'" , Richard Draves , "Hesham Soliman (EAB)" , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C28@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:57 PM 10/29/02, Hesham Soliman (EAB) wrote: > > or to put it another way, why do you have so much faith in > > filters of SL addresses and so little faith in filters of prefixes? > > > >=> Because they're not configured, they're hardcoded. No, they aren't. You can't hardcode site-local address filtering in every router, or you won't be able to communicate inside a site. So the router will need to be configured, somehow, to block site-local addresses from being forwarded from one interface to another. And that configuration isn't any more inviolate than a traditional forwarding filter. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 14:14:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TMEK29003862; Tue, 29 Oct 2002 14:14:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TMEKN7003861; Tue, 29 Oct 2002 14:14:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TMEH29003854 for ; Tue, 29 Oct 2002 14:14:17 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9TMEQMq002060 for ; Tue, 29 Oct 2002 14:14:26 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05384 for ; Tue, 29 Oct 2002 14:14:20 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 98C113B370 for ; Wed, 30 Oct 2002 09:14:15 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 30 Oct 2002 09:14:15 +1100 Message-Id: <1035929657.7840.30.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2002-10-30 at 08:29, Richard Draves wrote: > > > There is, however, a potential risk to using > > > site-local addresses > > > for long-lived connections. Those connections may > > > fail when a site > > > becomes partitioned, even if global connectivity is > > > still available > > > between the partitions. > > > > => FWIW, I think that one can see this as an advantage. > > An admin might not want these connections to survive > > when going through the Internet (outside the site). > > When the site was partitioned, an admin could have forgotten > > about these connections (?) and using site-local helped made > > this obvious. As opposed to having (potentially) sensitive > > data going over the public net. > > Yes of course that's an advantage. I can't imagine anyone (from > enterprise network administrator to home user) wanting intra-site > communication to suddenly be routed outside the site. > Surely there would be a both a sink route in your border routers for your own /48 global address ranges, and source address access list facing the Internet, preventing this from happening. This is common security practice. > 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 Tue Oct 29 15:03:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TN3L29004204; Tue, 29 Oct 2002 15:03:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TN3Lp0004203; Tue, 29 Oct 2002 15:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TN3I29004196 for ; Tue, 29 Oct 2002 15:03: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 g9TN3QbB005480 for ; Tue, 29 Oct 2002 15:03:27 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16544 for ; Tue, 29 Oct 2002 16:03:00 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9TN2rBM028695 for ; Wed, 30 Oct 2002 10:02:54 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210292302.g9TN2rBM028695@drugs.dv.isc.org> Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] In-reply-to: Your message of "Tue, 29 Oct 2002 13:22:17 CDT." <3DBED1D9.6020200@nc.rr.com> Date: Wed, 30 Oct 2002 10:02:53 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > > On Tue, 29 Oct 2002, Brian Haberman wrote: > > > >>>Note that KAME only supports this through manual configuration (and a > >>>fix) -- clarified in off-the-list discussion. > >>> > >>>To be compliant with the paragraph: > >>> > >>> Routers must not forward any packets with site-local source or > >>> destination addresses outside of the site. > >>> > >>>Note: it does not say 'packets from the site' (implying configuration of > >>>the site) but 'with site-local source'. That strongly implies explicit > >>>configuration will not satisfy. > >> > >>I don't read it that way at all. I interpret that to mean, if the > >>router is configured as a site-border router it must not forward those > >>packets out of the site. > > > > > > That kind of interpretation is easy (== activation logic in the > > implementation is simple) , but really, totally useless I believe. > > That depends on the model you believe. If we take Margaret's proposal > that, by default, a node is in one site (you treat SLs as globals) then > explicit config is needed to have a border router. In this scenario, > the site-local zone ids are all the same. > > The other case is where each interface is in different site (that makes > SLs equivalent to link-locals) and the site-local zone ids are all > unique. There is also the case where the number of sites < number of interfaces and number of sites != 1. e.g. interfaces 1 and 4 are in site 1 interfaces 2 and 5 are in site 2 interface 3 is in site 3 You have to allow SL traffic between 1 and 4 also between 2 and 5 but not between any other combination of interfaces. Mark > > > > The promise of using site-locals is that they will not propagate globally. > > > > Routers must make sure they don't do that, even without being configured > > as site-border routers. > > That would require routers to always act as a site border router. > > > > > If this wasn't true, nobody should be able to use site-locals even without > > relatively clean conscience, as nobody could be sure there _is_ a router > > that's blocking illegally-sourced site-locals from coming to my site or > > vice versa. > > > > The paragraph requires clarification for sure. > > How about removing it? > > > > > > >>The behavior is as defined in Section 5 of the scoped addr arch which > >>is all interfaces are in the same site, unless explicitly configured > >>by an administrator. > > > > > > Scoped arch draft is irrelevant from the perspective of addrarch > > (independence) IMO. > > What I meant is that any discussion similar to that paragraph should > be in the scoped addr arch. > > > > > > >>>1) node just blindly configures fec0::1 and starts sending traffic using > >>>it, testing how far it will go. > >>> > >>>A valid scenario here could be that site-locals would be used inside one > >>>link only -- no config at all in the router -- but the route must disallow > >>>propagation of site-locals through default route if something fails. > >> > >>That does not follow from the discussion in scoped addr arch. Of > >>course, this should be clarified in addr arch when we decide on the > >>SL content of that document. > > > > > > Better: _addrarch_ shouldn't say anything at all like that because we > > don't know how to do it (or can't write it down). > > Agreed. > > > > > > >>>You may ask: how is this possible? we don't have any site-border > >>>discovery mechanisms? > >>> > >>>I say: exactly, that's why the paragraph is so ridiculous! > >>> > >>>The only easy and compliant implementation I could think of would be > >>>discarding all site-locals unless some links are explicitly configured to > >>>be part of a site. > >> > >> From the discussion I have read, it seems that it would be more that > >>we are assuming that all interfaces are in the same site unless > >>explicitly configured. > > > > > > The risk of site-local leakage is _way_ too big that way. > > My statement is based on the proposal that site-locals be restricted > to disconnected networks. > > 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 > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 15:56:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TNuD29004788; Tue, 29 Oct 2002 15:56:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9TNuDTg004787; Tue, 29 Oct 2002 15:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9TNuA29004780 for ; Tue, 29 Oct 2002 15:56:10 -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 g9TNuIbB022265 for ; Tue, 29 Oct 2002 15:56:18 -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 QAA06856 for ; Tue, 29 Oct 2002 16:56:13 -0700 (MST) Message-ID: <003d01c27fa6$84d05660$5c6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Bound, Jim" , "Thomas Narten" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0C1C@Esealnt861.al.sw.ericsson.se> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 15:54:22 -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 Hesham, Do you anticipate that the changes in FMIPv6 for access routers will be in all IPv6 routers? jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'James Kempf'" ; "Bound, Jim" ; "Thomas Narten" Cc: Sent: Tuesday, October 29, 2002 10:08 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > I hear your concerns quite clearly. > > > > One possibility would be to make the FastRA and Optimistic > > DAD work specific to > > MIPv6 wireless access routers, and therefore not a general > > IPv6 router > > enhancement. > > => The problem is there is no such thing as wireless access > routers being bound to MIPv6 optimisations. The routers > we have in IETF meetings are wireless, but there is no IP > mobility going on. > > I think Jim's concerns (not you the other Jim :) ) can be > handled because Fast RA and optimistic DAD do not change anything > on the wire. In fact, Fast RAs have no impact on hosts at all. > I agree with Jim Bound that you should mention how the > designated router is known, but this can be done by > manual config as a default mechanism. > > Optimistic DAD needs to be analysed carefully to make sure > that the failure cases are rare and do not justify killing > optimistic DAD. I think this analysus is ongoing. > > Hesham > > I think this would address your concern about > > impacting current > > wired router product plans. It really is only for mobility, > > as a wired host > > rarely to never changes its link. > > > > That would move the work to the MIP group, as a separate > > but complementary item > > to the current FMIPv6 work. The optimized MIPv6 work is > > still not quite ready > > for prime time, but it is getting there. Of course, this > > would require approval > > of the ADs, MIP WG chairs, and MIP WG. > > > > How does that sound? > > > > jak > > > > ----- Original Message ----- > > From: "Bound, Jim" > > To: "James Kempf" ; "Thomas Narten" > > > > Cc: > > Sent: Tuesday, October 29, 2002 7:39 AM > > Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > > > > > James, > > > > > > ........................................Determination of > > > how this router is designated is outside the scope of this > > > document. An RA that is immediately unicast to the > > sender rather > > > than delayed is known as a "fast RA". > > > > > > I do not believe it should be outside the scope of this > > draft. I think > > > it imperative that this be defined clearly and a method > > proposed before > > > FAST RA can be bought into by IPv6 implementors. > > > > > > I also believe at this time the IESG should require a > > fairly good set of > > > reports from multiple implementations of this and other > > proposals for > > > wireless efforts that want to change DAD parameters and extend > > > attributes to ND and Stateless Addrconf. Right now the > > only work within > > > this space that has received the test of fire at UNH, > > ETSI, or TAHI as > > > examples is MIPv6. These tests beat hard on IPv6 implementation > > > enhancements as was just done for MIPv6 D-18 in Sophia > > Antipolis at > > > ETSI. I would suggest to the IESG doing any changes to > > ND or Addrconf > > > without serious hard core testing from this work is dangerous. > > > > > > If you, I, and others believe this is important then the > > code will get > > > done for this and Optimistic DAD and show up at the > > tests. Otherwise > > > this is purely a research and at best AD exercise. IPv6 > > is now being > > > deployed we cannot mess with DAD or Addr Conf in casual > > ways any more > > > than we do with IP (for v4), TCP, or RTT algrorithm for > > TCP as examples. > > > > > > I also believe all these efforts should begin to think > > like MIPv6 has > > > and that is they are separate documents and I strongly am > > against any > > > enhancments to ND or Addrconf from Fast RA, Optimistic > > DAD etc. They > > > should be new RFCs. > > > > > > All this also presents new security problems too that > > does not exist in > > > current ND and Addrconf on wired links. The base reason > > is that these > > > mess with the ND architecture and wired links that are > > firewalled or PKI > > > protected are more insulated than say 802.11b. > > > That being said I would like to see all security sections > > for this work > > > define what new security problems exist simply because of > > this behavior > > > not just say exists now in DAD or whatever. > > > > > > None of these options should be permitted for wire links > > (status quo) at > > > all. > > > That gives me an idea at least how the router to do Fast > > RA should be > > > defined. > > > > > > I would also like to see hard core router or switch > > "PRODUCT" developers > > > comment on this work and other work. I know routing code > > but not like > > > those that build ASICs and the like. > > > I would like to hear them say the pain and gain they feel > > or see from > > > this strategy. > > > > > > /jim > > > [Have you ever seen the rain coming down on a sunny day] > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Oct 29 16:15:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U0Fi29004959; Tue, 29 Oct 2002 16:15:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U0Fign004958; Tue, 29 Oct 2002 16:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U0Ff29004951 for ; Tue, 29 Oct 2002 16:15:41 -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 g9U0FobB027720 for ; Tue, 29 Oct 2002 16:15:50 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12417 for ; Tue, 29 Oct 2002 17:15:44 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9U0FZKV022899; Wed, 30 Oct 2002 01:15:35 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 01:15:35 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C29@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Bound, Jim" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 30 Oct 2002 01:15:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, > Do you anticipate that the changes in FMIPv6 for access > routers will be in all > IPv6 routers? => I don't know. But I know that any router can be an "access router". People don't develop a special router because it will be connected to an ethernet that has a an 802.11 base station at the other end. It's just a router, it can be connected anywhere. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 16:38:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U0cC29005278; Tue, 29 Oct 2002 16:38:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U0cCTh005277; Tue, 29 Oct 2002 16:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U0c729005261 for ; Tue, 29 Oct 2002 16:38: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 g9U0cGbB004452 for ; Tue, 29 Oct 2002 16:38:16 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03751 for ; Tue, 29 Oct 2002 17:38:01 -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 QAA23716; Tue, 29 Oct 2002 16:37:56 -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 QAA15521; Tue, 29 Oct 2002 16:37:57 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id QAA18663; Tue, 29 Oct 2002 16:40:38 -0800 (PST) Date: Tue, 29 Oct 2002 16:40:38 -0800 (PST) From: Tim Hartrick Message-Id: <200210300040.QAA18663@feller.mentat.com> To: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: RE: Limiting the Use of Site-Local X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I generally agree with all the points that Richard Draves has made. I am not as sanguine about the ease of implementation in the network stack but there is nothing in the details which is unimaginably difficult. We very much need to move on. By my count this is the forth or fifth time this topic has been debated and redebated. Each time the result has been the same. If every decision taken by this working group can be opened repeatedly by a noisy minority then forward progress of any sort will not be possible. Consensus does not require unanimity. No matter how noisy and persistent the minority happens to be, it is possible to move on. There are a couple of other points I would like to make. Some folks seem to be operating under a misconception about RFC 1918. RFC 1918 was a response to the rampant use of arbitrary IPv4 prefixes as private address space. The use of private address space was not a response to the publishing of RFC 1918. Network administrators will use "private" IPv6 address space whether we excise all mention of site-local addresses from the specifications or not. The network administrators that use private address space may be stupid, misinformed or have any number of socially unacceptable habits but they still run their networks and will run their networks the way they see fit. Removing site-local addresses from the architecture or attempting to restrict their use in a way that is equivalent to removing them is an exercise in futility absent better alternatives to site-local addresses. The burden on those that want to remove site-local addresses is to provide network administrators with an alternative which meets their needs but doesn't possess the negative aspects of site-local addresses that are being railed against. The requirements that network adminstrators would place on these addresses would probably be that there is no registration required and that the addresses are not globally routable. If such a proposal has been made and it has made it through last call of this working group, I must have missed it. Contrary to what has been said by some in the anti-site-local camp, the burden should be on them to come up with alternatives to site-local addresses. Until those alternatives have been thoroughly vetted by this working group the previous consensus should hold. Counter to what one might believe from reading my comments above, I don't like the architectural mess that has occured as a consequence of the use private addresses in IPv4. The difference between me and the anti-site- local camp is that I don't anticipate that network administrators will stop using private address (IPv6 or IPv4) unless they are provided with good reasons not to use them. That means solving renumbering, solving address shortage, artificial or otherwise, providing the an alternative "private" address scheme of the sort cited above and providing the great IPv6 applications which their customers want but that break in the presence of site-local addresses. If these things are done, it won't be necessary to add a bunch of MUST NOTs into the verbiage in various specifications. Site-local addresses and all the associated problems will fall into the dustbin of obsolescence. Absent these things, all the MUST NOTs in the world won't prevent the use of site-local addresses or some other form of IPv6 "private" address. Network administrators don't read RFCs for the MUST NOTs. They read them for the solutions they provide. If the MUST NOTs get in the way of the solution then they get ignored. 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 Oct 29 17:15:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1FW29005725; Tue, 29 Oct 2002 17:15:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U1FVWG005724; Tue, 29 Oct 2002 17:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1FS29005717 for ; Tue, 29 Oct 2002 17:15:28 -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 g9U1FbMq027693 for ; Tue, 29 Oct 2002 17:15:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20867 for ; Tue, 29 Oct 2002 17:15:32 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Oct 2002 17:15:35 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3D7@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/rgnN4Meu0yWYRdqjmykUM2CYwwAAvKWA From: "Michel Py" To: "Tim Hartrick" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9U1FS29005718 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am in complete agreement with Tim Hartrick's last posting. 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 Oct 29 17:41:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1fu29006100; Tue, 29 Oct 2002 17:41:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U1fuMM006099; Tue, 29 Oct 2002 17:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1fq29006092 for ; Tue, 29 Oct 2002 17:41:53 -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 g9U1g2Mq004768 for ; Tue, 29 Oct 2002 17:42:02 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21232 for ; Tue, 29 Oct 2002 17:41:56 -0800 (PST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9U1fpur021481; Tue, 29 Oct 2002 20:41:52 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 29 Oct 2002 20:41:34 -0500 Message-ID: <3DBF384B.9020606@nc.rr.com> Date: Tue, 29 Oct 2002 20:39:23 -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: Mark.Andrews@isc.org CC: ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] References: <200210292302.g9TN2rBM028695@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, Mark.Andrews@isc.org wrote: >>Pekka Savola wrote: >> >>>On Tue, 29 Oct 2002, Brian Haberman wrote: >>> >>> >>>>>Note that KAME only supports this through manual configuration (and a >>>>>fix) -- clarified in off-the-list discussion. >>>>> >>>>>To be compliant with the paragraph: >>>>> >>>>> Routers must not forward any packets with site-local source or >>>>> destination addresses outside of the site. >>>>> >>>>>Note: it does not say 'packets from the site' (implying configuration of >>>>>the site) but 'with site-local source'. That strongly implies explicit >>>>>configuration will not satisfy. >>>> >>>>I don't read it that way at all. I interpret that to mean, if the >>>>router is configured as a site-border router it must not forward those >>>>packets out of the site. >>> >>> >>>That kind of interpretation is easy (== activation logic in the >>>implementation is simple) , but really, totally useless I believe. >> >>That depends on the model you believe. If we take Margaret's proposal >>that, by default, a node is in one site (you treat SLs as globals) then >>explicit config is needed to have a border router. In this scenario, >>the site-local zone ids are all the same. >> >>The other case is where each interface is in different site (that makes >>SLs equivalent to link-locals) and the site-local zone ids are all >>unique. > > > There is also the case where the number of sites < number of interfaces > and number of sites != 1. > > e.g. > interfaces 1 and 4 are in site 1 > interfaces 2 and 5 are in site 2 > interface 3 is in site 3 > > You have to allow SL traffic between 1 and 4 also between > 2 and 5 but not between any other combination of interfaces. I agree that such a configuration should be allowed. My example was to point out the two possible default behaviors that could occur with no admin configuration. Brian > > Mark > > >>>The promise of using site-locals is that they will not propagate globally. >>> >>>Routers must make sure they don't do that, even without being configured >>>as site-border routers. >> >>That would require routers to always act as a site border router. >> >> >>>If this wasn't true, nobody should be able to use site-locals even without >>>relatively clean conscience, as nobody could be sure there _is_ a router >>>that's blocking illegally-sourced site-locals from coming to my site or >>>vice versa. >>> >>>The paragraph requires clarification for sure. >> >>How about removing it? >> >> >>> >>>>The behavior is as defined in Section 5 of the scoped addr arch which >>>>is all interfaces are in the same site, unless explicitly configured >>>>by an administrator. >>> >>> >>>Scoped arch draft is irrelevant from the perspective of addrarch >>>(independence) IMO. >> >>What I meant is that any discussion similar to that paragraph should >>be in the scoped addr arch. >> >> >>> >>> >>> >>>>>1) node just blindly configures fec0::1 and starts sending traffic using >>>>>it, testing how far it will go. >>>>> >>>>>A valid scenario here could be that site-locals would be used inside one >>>>>link only -- no config at all in the router -- but the route must disallow >>>>>propagation of site-locals through default route if something fails. >>>> >>>>That does not follow from the discussion in scoped addr arch. Of >>>>course, this should be clarified in addr arch when we decide on the >>>>SL content of that document. >>> >>> >>>Better: _addrarch_ shouldn't say anything at all like that because we >>>don't know how to do it (or can't write it down). >> >>Agreed. >> >> >>> >>>>>You may ask: how is this possible? we don't have any site-border >>>>>discovery mechanisms? >>>>> >>>>>I say: exactly, that's why the paragraph is so ridiculous! >>>>> >>>>>The only easy and compliant implementation I could think of would be >>>>>discarding all site-locals unless some links are explicitly configured to >>>>>be part of a site. >>>> >>>>From the discussion I have read, it seems that it would be more that >>>>we are assuming that all interfaces are in the same site unless >>>>explicitly configured. >>> >>> >>>The risk of site-local leakage is _way_ too big that way. >> >>My statement is based on the proposal that site-locals be restricted >>to disconnected networks. >> >>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 >>-------------------------------------------------------------------- > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 17:44:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1iO29006165; Tue, 29 Oct 2002 17:44:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U1iO3K006164; Tue, 29 Oct 2002 17:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1iJ29006154 for ; Tue, 29 Oct 2002 17:44: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 g9U1iSbB022185 for ; Tue, 29 Oct 2002 17:44:28 -0800 (PST) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28923 for ; Tue, 29 Oct 2002 18:44:22 -0700 (MST) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO9YIPFO3S95MY08@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 30 Oct 2002 12:41:21 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 693E012C06D; Wed, 30 Oct 2002 12:41:15 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id CE2AC12C113; Wed, 30 Oct 2002 12:38:38 +1100 (EST) Date: Wed, 30 Oct 2002 12:38:38 +1100 From: Greg Daley Subject: Re: Changing RS Reply Timing for Mobile IPv6 To: "Hesham Soliman (EAB)" Cc: "'James Kempf'" , "Bound, Jim" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3DBF381E.1080204@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4DA6EA82906FD511BE2F00508BCF0538044F0C29@Esealnt861.al.sw.ericsson.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, James, Jim, I think that the advantages of Opti-DAD particularly are that there's no dependence on support in Router infrastructure (beyond existing ND). With FastRA, the amount of state kept and the required code changes are miniscule (was an afternoon's work for the prototype, including configuration subsystem). There's really no strict relationship with these mechanisms and MIPv6 Fast Handovers, which requires significant changes in added signalling mechanisms in Access Routers, as well as neighboring routers/L2 access point mappings. Of course, they will play nicely with each other though, since both FastRA and OptiDAD are designed to interwork with existing IP standards and Mobile-IP drafts. As far as isolating FastRA from the core, I think that's relatively simple, even in the case where all routers ship identical code: The FastRA draft says that it's configurable and defaults to off. Greg Daley Hesham Soliman (EAB) wrote: > James, > > > Do you anticipate that the changes in FMIPv6 for access > > routers will be in all > > IPv6 routers? > > => I don't know. But I know that any router can be > an "access router". People don't develop a special router > because it will be connected to an ethernet that has a an > 802.11 base station at the other end. It's just a router, > it can be connected anywhere. > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 17:45:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1jp29006211; Tue, 29 Oct 2002 17:45:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U1jpGM006210; Tue, 29 Oct 2002 17:45:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U1jl29006200 for ; Tue, 29 Oct 2002 17:45:47 -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 g9U1jubB022647 for ; Tue, 29 Oct 2002 17:45:56 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06144 for ; Tue, 29 Oct 2002 18:45:50 -0700 (MST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9U1jOux026648; Tue, 29 Oct 2002 20:45:26 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 29 Oct 2002 20:45:09 -0500 Message-ID: <3DBF3922.8050803@nc.rr.com> Date: Tue, 29 Oct 2002 20:42:58 -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: Richard Draves CC: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: Forwarding packets with site-local source [Re: Choices to go forward with SL] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Richard Draves wrote: >>Some read it (many): >> >> "if I configure a site here, I must also block site-locals >>from spreading >>out or false site-locals coming in" >> >>Some others read it: >> >> "if I use site-locals here, my upstream router will block >>the site-local >>addresses from spreading out and prevent anyone from spoofing >>site-locals >>to my site" >> >>The latter is how I read it must be implemented -- and >>reading Microsoft's implementation and the reason they're >>using SL *strongly* suggests they >>also have read it that way. There are very probably many others. > > > No, I think you're the only person reading it the latter way. > > My expectation is that routers will need to be configured to understand > site boundaries. A conservative position is that routers by default > should regard their interfaces as belonging to different sites, unless > they are configured to be in the same site. Or perhaps other aspects of > the router's configuration (eg the network prefixes assigned to > different interfaces, or the routing protocols in use) could be used to > default the site configuration. I would be a little concerned with allowing a border configuration to be controlled by a routing protocol. A routing flap could do all sorts of nasty things in that situation. My take is that the two possible router configs for site locals is 1. All interfaces are in the same site 2. All interfaces are in unique sites Margaret's proposal that the default behavior is a node's interfaces are in 1 site results in case 1. For a router, a safer config may be 2. That would strictly limit the outward flow of site local addresses. 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 Oct 29 18:07:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U27K29006646; Tue, 29 Oct 2002 18:07:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U27Jal006645; Tue, 29 Oct 2002 18:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U27F29006638 for ; Tue, 29 Oct 2002 18:07: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 g9U27PMq011326 for ; Tue, 29 Oct 2002 18:07:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16575 for ; Tue, 29 Oct 2002 18:07:19 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9U27G029667; Tue, 29 Oct 2002 21:07:16 -0500 (EST) Message-Id: <200210300207.g9U27G029667@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Hartrick cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 16:40:38 PST.") <200210300040.QAA18663@feller.mentat.com> Date: Tue, 29 Oct 2002 21:07:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I generally agree with all the points that Richard Draves has made. I am > not as sanguine about the ease of implementation in the network stack > but there is nothing in the details which is unimaginably difficult. The network stack isn't the problem; the difficulty of handling SLs in applications, coupled with their lack of benefit, is the problem. > We very much need to move on. By my count this is the forth or fifth > time this topic has been debated and redebated. Each time the result has > been the same. No the result is not the same, because each time the debate crops up again there is less and less justification for SLs. The arguments for SL were always weak, by now when the burdens associated with SL are more apparent they're nearly indefensible. > If every decision taken by this working group can be > opened repeatedly by a noisy minority then forward progress of any > sort will not be possible. Consensus does not require unanimity. No > matter how noisy and persistent the minority happens to be, it is possible > to move on. Clearly we don't have a consensus that SLs are technically sound or that there is a compelling use case for them. That should argue for our not burdening the network with them. > There are a couple of other points I would like to make. > > Some folks seem to be operating under a misconception about RFC 1918. > RFC 1918 was a response to the rampant use of arbitrary IPv4 prefixes as > private address space. The use of private address space was not a response > to the publishing of RFC 1918. You are right about the first part, someone mistaken about the second. RFC 1918 was indeed a response to the use of arbitrary IPv4 prefixes; and surely it was better to use a standard set of prefixes than arbitrary ones. But RFC 1918 has also repeatedly been cited to give license to hooking private networks to the public Internet via NAT despite careful wording in RFC 1918 to NOT license such use. > Removing site-local addresses from the > architecture or attempting to restrict their use in a way that is equivalent > to removing them is an exercise in futility absent better alternatives > to site-local addresses. Network admins can indeed screw with their networks and harm interoperability of the global network by doing so, and there's nothing that we can do to prevent them from doing that. But it's not IETF's purpose to tell network admins that it's okay to harm the network. Rather, it's IETF's purpose to tell them how the network was designed to be used and which practices for using the network make good sense. SLs do not make good sense. > The burden on those that want to remove site-local addresses is to provide > network administrators with an alternative which meets their needs but > doesn't possess the negative aspects of site-local addresses that are > being railed against. No, the burden on those who want to promote site-local is to figure out how to have SLs exist without limiting the ability of the network to support multiparty apps and without imposing a considerable burden on such apps. We need justification to keep complex and burdensome features, not to justify getting rid of them (or replacing them with simpler features). > The requirements that network adminstrators > would place on these addresses would probably be that there is no registration > required I think you're stating it a bit strongly. I would say that there needs to be a low barrier to obtaining addresses and that the process be easily and widely understood. But this doesn't by itself preclude some kind of registration. Sites don't seem to have major problems registering domain names, for instance. > and that the addresses are not globally routable. If such a > proposal has been made and it has made it through last call of this working > group, I must have missed it. I've seen multiple proposals along these lines. I certainly agree that these are needed - as I've said on multiple occasions, they are needed to facilitate private interconnection between private networks. > Contrary to what has been said by some > in the anti-site-local camp, the burden should be on them to come up with > alternatives to site-local addresses. Until those alternatives have been > thoroughly vetted by this working group the previous consensus should hold. It seems to me that there's nowhere approaching a consensus to keep SLs except for isolated networks. > Counter to what one might believe from reading my comments above, I don't > like the architectural mess that has occured as a consequence of the use > private addresses in IPv4. The difference between me and the anti-site- > local camp is that I don't anticipate that network administrators will > stop using private address (IPv6 or IPv4) unless they are provided with > good reasons not to use them. That means solving renumbering, solving > address shortage, artificial or otherwise, providing the an alternative > "private" address scheme of the sort cited above I agree with the above. We *really* need to work on a complete story for renumbering. We *really* need a way for sites to get non-publically-routable (but routable between private networks), provider-independent address space. > and providing the great > IPv6 applications which their customers want but that break in the presence > of site-local addresses. this part makes no sense. applications that don't work under such conditions don't get deployed very far - and people never get to use them. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 19:07:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U37M29007519; Tue, 29 Oct 2002 19:07:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U37Mgs007518; Tue, 29 Oct 2002 19:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U37I29007511 for ; Tue, 29 Oct 2002 19:07:18 -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 g9U37QbB011369 for ; Tue, 29 Oct 2002 19:07:27 -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 UAA00652 for ; Tue, 29 Oct 2002 20:07:21 -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 TAA24483; Tue, 29 Oct 2002 19:07:11 -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 TAA20540; Tue, 29 Oct 2002 19:07:11 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id TAA18792; Tue, 29 Oct 2002 19:09:55 -0800 (PST) Date: Tue, 29 Oct 2002 19:09:55 -0800 (PST) From: Tim Hartrick Message-Id: <200210300309.TAA18792@feller.mentat.com> To: moore@cs.utk.edu Subject: Re: Limiting the Use of Site-Local Cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > > > and providing the great > > IPv6 applications which their customers want but that break in the presence > > of site-local addresses. > > this part makes no sense. applications that don't work under such > conditions don't get deployed very far - and people never get to use them. > No, you just missed the point. Compelling applications that don't work with site-local addresses will render the use of site-local addresses extinct. Customers that pay money will guarantee that, as long as there are no other reasons to be using site-local addresses (address scarcity, renumbering not working etc.). I am willing to believe that such applications will exist and that the other issues which would drive the NAT'ification of IPv6 can be overcome. But I am not willing to bet the farm on it and have to reinvent IPv6 RFC 1918 after the fact and police up all the mess that has been created in the interim by system administrators that allocated chunks of global address space that they didn't own. We need to have a viable alternative to site- local addresses rather than hanging our hat on puritanical proscriptions which are going to be ignored unless the problems are solved (renumbering, address scarcity, etc.). No such alternative has been proposed and achieved consensus. 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 Oct 29 20:57:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U4ve29008041; Tue, 29 Oct 2002 20:57:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U4veOF008040; Tue, 29 Oct 2002 20:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U4va29008033 for ; Tue, 29 Oct 2002 20:57:36 -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 g9U4vjbB026894 for ; Tue, 29 Oct 2002 20:57:45 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25304 for ; Tue, 29 Oct 2002 20:57:40 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9U4vZ000473; Tue, 29 Oct 2002 23:57:35 -0500 (EST) Message-Id: <200210300457.g9U4vZ000473@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Hartrick cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 29 Oct 2002 19:09:55 PST.") <200210300309.TAA18792@feller.mentat.com> Date: Tue, 29 Oct 2002 23:57:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > and providing the great > > > IPv6 applications which their customers want but that break in the presence > > > of site-local addresses. > > > > this part makes no sense. applications that don't work under such > > conditions don't get deployed very far - and people never get to use them. > > No, you just missed the point. Compelling applications that don't work > with site-local addresses will render the use of site-local addresses extinct. no, *you* just missed the point. those apps never have a chance to prove their worth if the network is hostile to them. > I am willing to believe that such applications will exist and > that the other issues which would drive the NAT'ification of IPv6 can be > overcome. But I am not willing to bet the farm on it and have to reinvent > IPv6 RFC 1918 after the fact and police up all the mess that has been created > in the interim by system administrators that allocated chunks of global address > space that they didn't own. And *I'm* not willing to bet the farm by having SLs widely used based on vague claims and no evidence that they're actually useful and won't cause harm. Perhaps they're actually useful for something, but I know from firsthand experience that they cause harm and that the problems aren't easily solved. > We need to have a viable alternative to site-local addresses rather than > hanging our hat on puritanical proscriptions which are going to be ignored > unless the problems are solved (renumbering, address scarcity, etc.). I'm fully in agreement that we have to solve these problems. (though I don't think "address scarcity" is a good description of the problem I think you're describing - I had very little trouble getting /48 of stable,global IPv6 space for my home network using 6to4) > No such alternative has been proposed and achieved consensus. well, we don't have consensus on SL being a solution to anything either, except address allocation for isolated networks; nor do we have a consensus that SL is worth the cost imposed for applications. so we have several recognized problems with no consensus on any solutions. and something tells me we're not going to be able to solve the problems until we face reality about the limitaitons of not only SLs but also about of our current ideas about address allocation and renumbering. so if the problem is that people don't want to abandon SLs because we haven't found any other solutions to those problems yet (even when SLs don't actually solve some of those problems either), maybe it would help to get conesnsus that those other problems exist? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 21:04:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U54Y29008106; Tue, 29 Oct 2002 21:04:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U54YpX008105; Tue, 29 Oct 2002 21:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U54V29008098 for ; Tue, 29 Oct 2002 21:04:31 -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 g9U54ebB028014 for ; Tue, 29 Oct 2002 21:04:40 -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 WAA12227 for ; Tue, 29 Oct 2002 22:04:34 -0700 (MST) Message-ID: <011e01c27fd1$85d0eef0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Bound, Jim" , "Thomas Narten" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0C29@Esealnt861.al.sw.ericsson.se> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Tue, 29 Oct 2002 21:02:07 -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 > > Do you anticipate that the changes in FMIPv6 for access > > routers will be in all > > IPv6 routers? > > => I don't know. But I know that any router can be > an "access router". People don't develop a special router > because it will be connected to an ethernet that has a an > 802.11 base station at the other end. It's just a router, > it can be connected anywhere. > I think what I've been hearing from Jim Bound and others that they would rather not have these specialized features that FMIPv6 is specifying as general purpose for any IPv6 router, because they want to move forward with their IPv6 (including base MIPv6 which works with any IPv6 router) product plans. I would argue that the oDAD and FastRA are in the same category. Thus, I think it makes sense to consider the oDAD and FastRA work as an optimized mobility enhancement, since I see no real need for it in wired networks. Most wired hosts will only do DAD once per boot, and if it takes an additional second, it's not such a big deal. On the other hand, if it takes a second for a mobile node to do a handover, it is a very big deal indeed. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 29 21:53:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U5rh29008379; Tue, 29 Oct 2002 21:53:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9U5rhFX008378; Tue, 29 Oct 2002 21:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9U5rc29008364 for ; Tue, 29 Oct 2002 21:53:38 -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 g9U5rlbB005322 for ; Tue, 29 Oct 2002 21:53:47 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16619 for ; Tue, 29 Oct 2002 21:53:40 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 9E7113B370; Wed, 30 Oct 2002 16:53:37 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com In-Reply-To: <200210300040.QAA18663@feller.mentat.com> References: <200210300040.QAA18663@feller.mentat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 30 Oct 2002 16:53:37 +1100 Message-Id: <1035957218.7840.286.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, I can provide a one network administrator's view, because that is all I am. In my experience, the main reasons network admins adopted RFC 1918 addressing were (in my naive days, I was one of them, thankforly(sp?) not for long) : 1) the "security" benefits of non-routable address space. 2) the perception that public Internet address space was hard to get, if not impossible. The main justification for site local addressing in IPv6 seems to be so that long lived TCP connections can survive site address renumbering. While this sounds like a worthy goal, I wonder how many organisations (individuals, enterprises, carriers) really have this requirement, other than those mobile users that are served by Mobile IPv6. Combining RFC1918 addressing with NAT would meet the same goal in the IPv4 world, irrespective of the previous two reasons I suggested for net admins adopting RFC1918 addressing. RFC1918 addressing in combination with NAT effectively gives an organisation provider independant addressing. An organisation can change their ISP, with a fairly simple change to their NAT rules, having no impact on their long lived internal TCP connections, and avoiding them having to renumber their internal hosts. Yet I've never heard of anybody implementing RFC1918/NAT for provider independent addressing reasons. I'm sure there are probably instances, but I think they are probably pretty rare. It seems to me that the site local addressing feature suffers from a problem of the perceived benefits being far higher than the actual benefits. The people on the anti-site local side fear the complexity, the issues of passing scope, strangely failed connections due to passing the wrong type (global/site) of address. As a network admin, I ask questions such as "what is the geographical definition or size of a site when using site-local addressing". Here in Australia it is quite common to have a data center in Sydney or Melbourne, with the other major capital cities accessing it via a large WAN (eg links typically 500 Miles or so long). If I was to follow the true "site" definition of site-locals, I would treat each office in each capital as a site, meaning that the interstate TCP connections would be using global addresses - and therefore wouldn't survive a renumbering involving global addressing. However, with a /48 available for site local addressing, I'd be smarter to treat the whole of Australia as a site, and avoid the global address renumbering issues. So the name of "site-locals" is already wrong, but things would be ok. "site-local" addressing should maybe be called "continent-local" addressing perhaps. Then I have to connect to an office in New Zealand (geographically fairly close to Sydney), another continent. For the same, long-lived TCP connection reasons, I'd probably include New Zealand as part of the same instance of site-local addressing that I've created across Australia. Hmm, not really continent-local addressing anymore. If my company was now to merge with another company, who also had a smart network admin (like me :-) ), who had also rolled out site-local addressing across Australia, there is a reasonable chance that there is overlap between our two separate instances of site-local addressing. We could ring up our favorite vendor and say "do you sell IPv6 NAT boxes, we need to translate between our two instances of site-local addressing". This might be preferable to having to go and renumber manually the site-local addressing that intersects across the two instances. Alternatively we might be able to use the router renumbering protocol. However, if we don't use IPv6 NAT (presuming it exists), we have a site-local renumbering event, which is going to impact some long lived TCP connections - which is what site-locals addressing appears to be trying to prevent. In this example, I have already increased the geographic definition of site-local addressing to better suit my needs, and yet still have not managed to avoid renumbering issues. Using a pure "site-local" definition of a site, my long lived TCP connection problems are worse. So why bother with site locals at all ? At least with global addressing I could merge the two companies without having to renumber the networks, just push some backdoor routes around between them. Long lived TCP connections within the domains of the previous organisations networks will not be impacted. If one of the ISPs wants to renumber, or we choose to change ISPs, well, yes, the long lived TCP connections will go down, but that is a managed and scheduled event. It can be planned in advance, people can take appropriate measures to deal with it. I'd much rather deal with very occasional, managed renumbering events, than all the unscheduled failure events that can occur in a network, day in day out. And that, as a network admin type person, is why I wonder what the value of site-local addressing is. Thanks for listening, Mark. On Wed, 2002-10-30 at 11:40, Tim Hartrick wrote: > > > All, > > I generally agree with all the points that Richard Draves has made. I am > not as sanguine about the ease of implementation in the network stack > but there is nothing in the details which is unimaginably difficult. > We very much need to move on. By my count this is the forth or fifth > time this topic has been debated and redebated. Each time the result has > been the same. If every decision taken by this working group can be > opened repeatedly by a noisy minority then forward progress of any > sort will not be possible. Consensus does not require unanimity. No > matter how noisy and persistent the minority happens to be, it is possible > to move on. > > There are a couple of other points I would like to make. > > Some folks seem to be operating under a misconception about RFC 1918. > RFC 1918 was a response to the rampant use of arbitrary IPv4 prefixes as > private address space. The use of private address space was not a response > to the publishing of RFC 1918. Network administrators will use "private" > IPv6 address space whether we excise all mention of site-local addresses > from the specifications or not. The network administrators that use private > address space may be stupid, misinformed or have any number of socially > unacceptable habits but they still run their networks and will run their > networks the way they see fit. Removing site-local addresses from the > architecture or attempting to restrict their use in a way that is equivalent > to removing them is an exercise in futility absent better alternatives > to site-local addresses. > > The burden on those that want to remove site-local addresses is to provide > network administrators with an alternative which meets their needs but > doesn't possess the negative aspects of site-local addresses that are > being railed against. The requirements that network adminstrators > would place on these addresses would probably be that there is no registration > required and that the addresses are not globally routable. If such a > proposal has been made and it has made it through last call of this working > group, I must have missed it. Contrary to what has been said by some > in the anti-site-local camp, the burden should be on them to come up with > alternatives to site-local addresses. Until those alternatives have been > thoroughly vetted by this working group the previous consensus should hold. > > Counter to what one might believe from reading my comments above, I don't > like the architectural mess that has occured as a consequence of the use > private addresses in IPv4. The difference between me and the anti-site- > local camp is that I don't anticipate that network administrators will > stop using private address (IPv6 or IPv4) unless they are provided with > good reasons not to use them. That means solving renumbering, solving > address shortage, artificial or otherwise, providing the an alternative > "private" address scheme of the sort cited above and providing the great > IPv6 applications which their customers want but that break in the presence > of site-local addresses. If these things are done, it won't be necessary > to add a bunch of MUST NOTs into the verbiage in various specifications. > Site-local addresses and all the associated problems will fall into the > dustbin of obsolescence. Absent these things, all the MUST NOTs in the > world won't prevent the use of site-local addresses or some other form of > IPv6 "private" address. > > Network administrators don't read RFCs for the MUST NOTs. They read them > for the solutions they provide. If the MUST NOTs get in the way of the > solution then they get ignored. > > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 04:00:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UC0529009363; Wed, 30 Oct 2002 04:00:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UC05d4009362; Wed, 30 Oct 2002 04:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UC0029009355 for ; Wed, 30 Oct 2002 04:00:01 -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 g9UC08bB025701 for ; Wed, 30 Oct 2002 04:00:09 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01272 for ; Wed, 30 Oct 2002 05:00:03 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UBxvQ2026646; Wed, 30 Oct 2002 12:59:58 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 12:59:57 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C32@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Bound, Jim" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 30 Oct 2002 12:59:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think what I've been hearing from Jim Bound and others > that they would rather > not have these specialized features that FMIPv6 is > specifying as general purpose > for any IPv6 router, because they want to move forward with > their IPv6 > (including base MIPv6 which works with any IPv6 router) > product plans. I would > argue that the oDAD and FastRA are in the same category. => I would strongly suggest that we decouple Fast RA and even oDAD from Fast handovers. These proposals will make MIPv6 handovers faster, independently of FMIPv6. So please consider them in isolation. This way we will also have the benefit of moving them forward ASAP and not waiting for FMIPv6. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 04:57:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UCv429009706; Wed, 30 Oct 2002 04:57:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UCv33i009705; Wed, 30 Oct 2002 04:57:03 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UCv029009698 for ; Wed, 30 Oct 2002 04:57:00 -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 g9UCv9Mq023026 for ; Wed, 30 Oct 2002 04:57:09 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11125 for ; Wed, 30 Oct 2002 04:57:03 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UCux310292; Wed, 30 Oct 2002 14:56:59 +0200 Date: Wed, 30 Oct 2002 14:56:59 +0200 (EET) From: Pekka Savola To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: Forwarding packets with site-local source [Re: Choices to go forward with SL] 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, 29 Oct 2002, Richard Draves wrote: > > The latter is how I read it must be implemented -- and > > reading Microsoft's implementation and the reason they're > > using SL *strongly* suggests they > > also have read it that way. There are very probably many others. > > No, I think you're the only person reading it the latter way. > > My expectation is that routers will need to be configured to understand > site boundaries. A conservative position is that routers by default > should regard their interfaces as belonging to different sites, unless > they are configured to be in the same site. Or perhaps other aspects of > the router's configuration (eg the network prefixes assigned to > different interfaces, or the routing protocols in use) could be used to > default the site configuration. I feared as much. Somehow I had hoped MS had learned the lesson. This practically seems to make site-locals totally useless due to non-existant security in current unamanaged networks, at the very least. Nobody can bind to site-local addresses unless he can be double sure the upstream routers actually are configured with the site boundary towards the global internet. (Without even getting into the application problems..) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 05:10:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UDA829009818; Wed, 30 Oct 2002 05:10:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UDA7ZN009817; Wed, 30 Oct 2002 05:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UDA429009810 for ; Wed, 30 Oct 2002 05:10:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UDACMq024747 for ; Wed, 30 Oct 2002 05:10:12 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24055 for ; Wed, 30 Oct 2002 06:10:06 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UD9u110426; Wed, 30 Oct 2002 15:09:57 +0200 Date: Wed, 30 Oct 2002 15:09:56 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Tim Hartrick , , Subject: SL and renumbering [Re: Limiting the Use of Site-Local] In-Reply-To: <200210300207.g9U27G029667@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Oct 2002, Keith Moore wrote: > > Counter to what one might believe from reading my comments above, I don't > > like the architectural mess that has occured as a consequence of the use > > private addresses in IPv4. The difference between me and the anti-site- > > local camp is that I don't anticipate that network administrators will > > stop using private address (IPv6 or IPv4) unless they are provided with > > good reasons not to use them. That means solving renumbering, solving > > address shortage, artificial or otherwise, providing the an alternative > > "private" address scheme of the sort cited above > > I agree with the above. We *really* need to work on a complete > story for renumbering. We *really* need a way for sites to get > non-publically-routable (but routable between private networks), > provider-independent address space. In the multi6 wg, there have been some proposals on the table on geographically assingned PI addresses. If for nothing else, they could be useful in renumbering scenarios; having two sets of addresses, one which do not depend on your ISP, should make the renumbering a bit less painful. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 05:16:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UDGX29009887; Wed, 30 Oct 2002 05:16:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UDGWjw009886; Wed, 30 Oct 2002 05:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UDGT29009879 for ; Wed, 30 Oct 2002 05:16: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 g9UDGbbB004913 for ; Wed, 30 Oct 2002 05:16:38 -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 GAA26629 for ; Wed, 30 Oct 2002 06:16:31 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UDGJB10518; Wed, 30 Oct 2002 15:16:20 +0200 Date: Wed, 30 Oct 2002 15:16:19 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021029171016.07aeb4f0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Oct 2002, Margaret Wasserman wrote: > At 04:57 PM 10/29/02, Hesham Soliman (EAB) wrote: > > > > or to put it another way, why do you have so much faith in > > > filters of SL addresses and so little faith in filters of prefixes? > > > > > > >=> Because they're not configured, they're hardcoded. > > No, they aren't. > > You can't hardcode site-local address filtering in every router, > or you won't be able to communicate inside a site. > > So the router will need to be configured, somehow, to block > site-local addresses from being forwarded from one interface > to another. And that configuration isn't any more inviolate > than a traditional forwarding filter. To (try to) clarify: the SL filters can be defined by hardcoding them (basically just two trivial access-lists for example), but they cannot be _enabled_ except manually or by some rather complex logic. .. thus making the argument about the ease of use pretty much irrelevant IMO .. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 06:16:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UEGd29010143; Wed, 30 Oct 2002 06:16:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UEGdji010142; Wed, 30 Oct 2002 06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UEGa29010135 for ; Wed, 30 Oct 2002 06:16:36 -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 g9UEGiMq003053 for ; Wed, 30 Oct 2002 06:16:44 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28191 for ; Wed, 30 Oct 2002 06:16:39 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA26272; Wed, 30 Oct 2002 06:16:19 -0800 (PST) Message-Id: <5.1.0.14.2.20021030091503.07aeabc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 09:17:44 -0500 To: Pekka Savola From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , Richard Draves , In-Reply-To: References: <5.1.0.14.2.20021029171016.07aeb4f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You can't hardcode site-local address filtering in every router, > > or you won't be able to communicate inside a site. > > > > So the router will need to be configured, somehow, to block > > site-local addresses from being forwarded from one interface > > to another. And that configuration isn't any more inviolate > > than a traditional forwarding filter. > >To (try to) clarify: the SL filters can be defined by hardcoding them >(basically just two trivial access-lists for example), but they cannot be >_enabled_ except manually or by some rather complex logic. > >.. thus making the argument about the ease of use pretty much irrelevant >IMO .. Exactly. It makes any argument that site-local filters are more "secure" than global filters pretty much irrelevant, too... If you can compromise the edge router and change its configuration, you can get either intra-site global or site-local traffic to be forwarded outside of the site. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 06:29:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UETq29010205; Wed, 30 Oct 2002 06:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UEThNY010204; Wed, 30 Oct 2002 06:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UESx29010194 for ; Wed, 30 Oct 2002 06:29:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UET6bB014531 for ; Wed, 30 Oct 2002 06:29:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00727 for ; Wed, 30 Oct 2002 07:28:59 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UESml11297; Wed, 30 Oct 2002 16:28:48 +0200 Date: Wed, 30 Oct 2002 16:28:48 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , "'Keith Moore'" , Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021030091503.07aeabc0@mail.windriver.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, 30 Oct 2002, Margaret Wasserman wrote: > > > You can't hardcode site-local address filtering in every router, > > > or you won't be able to communicate inside a site. > > > > > > So the router will need to be configured, somehow, to block > > > site-local addresses from being forwarded from one interface > > > to another. And that configuration isn't any more inviolate > > > than a traditional forwarding filter. > > > >To (try to) clarify: the SL filters can be defined by hardcoding them > >(basically just two trivial access-lists for example), but they cannot be > >_enabled_ except manually or by some rather complex logic. > > > >.. thus making the argument about the ease of use pretty much irrelevant > >IMO .. > > Exactly. > > It makes any argument that site-local filters are more "secure" > than global filters pretty much irrelevant, too... > > If you can compromise the edge router and change its configuration, > you can get either intra-site global or site-local traffic to be > forwarded outside of the site. Totally agree; but I'd also add a simpler case: someone forgot to explicitly configure (or like I did, when reading the spec -- assumed that it should get done automatically) the site scope in the edge router(s). Whoops! Watching the amount of spoofed traffic nowadays, most of which could be prevented by proper filtering, doesn't give me any reassuration that people would actually do this too.. and then wonder why their private site-local address space has been compromised.. (Note that the above clarification implicitly considered multi-sited routers out of scope: they will both have to be manually defined and manually taken to use. Even the simple case is so difficult to do properly.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 07:53:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UFrX29010701; Wed, 30 Oct 2002 07:53:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UFrXhJ010700; Wed, 30 Oct 2002 07:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UFrT29010693 for ; Wed, 30 Oct 2002 07:53:29 -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 g9UFrbMq024782 for ; Wed, 30 Oct 2002 07:53:38 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26935 for ; Wed, 30 Oct 2002 08:53:32 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UFrPQ1014419; Wed, 30 Oct 2002 16:53:25 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 16:53:25 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C38@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" Cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 16:53:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, I'm trying to understand this comment. > > >.. thus making the argument about the ease of use pretty > much irrelevant > > >IMO .. > > > > Exactly. > > > > It makes any argument that site-local filters are more "secure" > > than global filters pretty much irrelevant, too... > > > > If you can compromise the edge router and change its > configuration, > > you can get either intra-site global or site-local traffic to be > > forwarded outside of the site. > > Totally agree; but I'd also add a simpler case: someone forgot to > explicitly configure (or like I did, when reading the spec > -- assumed that > it should get done automatically) the site scope in the > edge router(s). > Whoops! > > Watching the amount of spoofed traffic nowadays, most of > which could be > prevented by proper filtering, doesn't give me any reassuration that > people would actually do this too.. and then wonder why > their private > site-local address space has been compromised.. => Are you saying that site-local traffic would start leaking outside the site and routed globally? As in transient ISPs will just forward it? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 08:04:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UG4629010814; Wed, 30 Oct 2002 08:04:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UG46hW010813; Wed, 30 Oct 2002 08:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UG4329010806 for ; Wed, 30 Oct 2002 08:04:03 -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 g9UG4BMq027315 for ; Wed, 30 Oct 2002 08:04:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25282 for ; Wed, 30 Oct 2002 08:04:05 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UG42h12138; Wed, 30 Oct 2002 18:04:02 +0200 Date: Wed, 30 Oct 2002 18:04:01 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C38@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 30 Oct 2002, Hesham Soliman (EAB) wrote: > > > >.. thus making the argument about the ease of use pretty > > much irrelevant > > > >IMO .. > > > > > > Exactly. > > > > > > It makes any argument that site-local filters are more "secure" > > > than global filters pretty much irrelevant, too... > > > > > > If you can compromise the edge router and change its > > configuration, > > > you can get either intra-site global or site-local traffic to be > > > forwarded outside of the site. > > > > Totally agree; but I'd also add a simpler case: someone forgot to > > explicitly configure (or like I did, when reading the spec > > -- assumed that > > it should get done automatically) the site scope in the > > edge router(s). > > Whoops! > > > > Watching the amount of spoofed traffic nowadays, most of > > which could be > > prevented by proper filtering, doesn't give me any reassuration that > > people would actually do this too.. and then wonder why > > their private > > site-local address space has been compromised.. > > => Are you saying that site-local traffic would start > leaking outside the site and routed globally? > As in transient ISPs will just forward it? Of course the ISP's will forward them -- they (probably) haven't been configured to be part of any sites (remember the two interpretations of the MUST NOT forward paragraph earlier). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 09:13:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UHDL29011306; Wed, 30 Oct 2002 09:13:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UHDK3G011305; Wed, 30 Oct 2002 09:13:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UHDH29011298 for ; Wed, 30 Oct 2002 09:13:17 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UHDQMq014824 for ; Wed, 30 Oct 2002 09:13:26 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18918 for ; Wed, 30 Oct 2002 09:13:20 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9UHDJFT090946 for ; Wed, 30 Oct 2002 12:13:20 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9UHDHDd059162 for ; Wed, 30 Oct 2002 12:13:17 -0500 Importance: Normal Sensitivity: Subject: IPv6 MIB team - new RFC2011 draft To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Wed, 30 Oct 2002 12:13:18 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/30/2002 10:13:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding the ipv6InterfaceTable in the new RFC2011 draft, it looks like there is a typo in the names of the Reachable and Retransmit time MIB object names. Shoud the names be ipv6Interface...Time or ipv6Inteface...Time? 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 Oct 30 09:27:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UHR629011418; Wed, 30 Oct 2002 09:27:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UHR6mv011417; Wed, 30 Oct 2002 09:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UHR329011410 for ; Wed, 30 Oct 2002 09:27: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 g9UHRBMq018648 for ; Wed, 30 Oct 2002 09:27:11 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27725 for ; Wed, 30 Oct 2002 09:27:06 -0800 (PST) Message-ID: <002301c28039$517b1ff0$4a6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Bound, Jim" , "Thomas Narten" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0C32@Esealnt861.al.sw.ericsson.se> Subject: Re: Changing RS Reply Timing for Mobile IPv6 Date: Wed, 30 Oct 2002 09:25:15 -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 Hesham, I wasn't proposing that they be coupled. I see the two as complimentary. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'James Kempf'" ; "Bound, Jim" ; "Thomas Narten" Cc: Sent: Wednesday, October 30, 2002 3:59 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > > > I think what I've been hearing from Jim Bound and others > > that they would rather > > not have these specialized features that FMIPv6 is > > specifying as general purpose > > for any IPv6 router, because they want to move forward with > > their IPv6 > > (including base MIPv6 which works with any IPv6 router) > > product plans. I would > > argue that the oDAD and FastRA are in the same category. > > => I would strongly suggest that we decouple Fast RA and > even oDAD from Fast handovers. These proposals will make > MIPv6 handovers faster, independently of FMIPv6. So please > consider them in isolation. This way we will also have > the benefit of moving them forward ASAP and not waiting > for FMIPv6. > > Hesham > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 10:42:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UIg929011832; Wed, 30 Oct 2002 10:42:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UIg9XH011831; Wed, 30 Oct 2002 10:42:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UIg629011824 for ; Wed, 30 Oct 2002 10:42: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 g9UIgDbB019337 for ; Wed, 30 Oct 2002 10:42:14 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25460 for ; Wed, 30 Oct 2002 11:42:08 -0700 (MST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9UIfoiZ004010 for ; Wed, 30 Oct 2002 13:41:50 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 13:41:47 -0500 Message-ID: <3DC028E1.4060605@nc.rr.com> Date: Wed, 30 Oct 2002 13:45:53 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Default site-local behavior for routers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, one of the items that Margaret suggested was some text in the node requirements doc or the scoped addr arch that states that nodes default to being in one site. However, there has been some mention that people would prefer different behavior in routers. That is, the stated desire was that, by default, each interface on a router be in its own site. This suggestion leads to the model where hosts with multiple interfaces will assume that all its interfaces are in the same site (e.g. have the same site-local zone id) unless explicitly configured to have multiple sites. While routers will default to having a unique site-local zone id for each interface (thus rendering SLs to link-local behavior) unless explicitly configured to have multiple interfaces in the same site. This difference in behavior for hosts and routers leads to some interesting issues. One big one is how the site-local zone ids are setup and potentially changed when a host becomes a router or vice versa. What are others' opinions on this issue? 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 Oct 30 12:17:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKHN29012681; Wed, 30 Oct 2002 12:17:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UKHNJt012680; Wed, 30 Oct 2002 12:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKHJ29012673 for ; Wed, 30 Oct 2002 12:17:20 -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 g9UKHRMq012421 for ; Wed, 30 Oct 2002 12:17:27 -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 NAA15530 for ; Wed, 30 Oct 2002 13:17:22 -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 g9UKHLE4033264; Wed, 30 Oct 2002 15:17:21 -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.4) with ESMTP id g9UKG4R4115490; Wed, 30 Oct 2002 13:16:04 -0700 In-Reply-To: <3DC028E1.4060605@nc.rr.com> To: Brian Haberman Cc: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers MIME-Version: 1.0 Sensitivity: 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 10/30/2002 03:10:45 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 10/30/2002 03:10:45 PM, Serialize complete at 10/30/2002 03:10:46 PM, S/MIME Sign failed at 10/30/2002 03:10:46 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0|September 26, 2002) at 10/30/2002 13:16:04, Serialize complete at 10/30/2002 13:16:04 Message-ID: Date: Wed, 30 Oct 2002 15:16:02 -0500 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This suggestion leads to the model where hosts with multiple > interfaces will assume that all its interfaces are in the > same site (e.g. have the same site-local zone id) unless > explicitly configured to have multiple sites. While routers > will default to having a unique site-local zone id for each > interface (thus rendering SLs to link-local behavior) unless > explicitly configured to have multiple interfaces in the > same site. > > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. > > What are others' opinions on this issue? The correct default really depends on the intended use of the node. Having interfaces default to being in different site-local scope zones makes sense for specialized boxes whose purpose is to be a site boundary router, like a home gateway router which has a WAN interface and one or more LAN interfaces. For these types of specialized nodes, it probably makes sense to default the WAN interface to one site-local scope zone and the LAN interface(s) to a separate site-local scope zone. The same type of logic could be applied to nodes which act as firewalls, where the "public" interfaces are in one site-local scope zone and the "private" intranet interfaces are in a different site-local scope zone. In this case, other configuration information can be used to derive the default site-local scope zones for the firewall's interfaces. For a typical host or router, though, a better default would be to have all interfaces in the same site-local scope zone. This is more consistent with what is shipping today. Indeed, many of the routers which ship today are not capable of being configured as a site boundary router, much less default to that behavior. Keep in mind that vast majority of hosts also support IP forwarding (although it may not be enabled by default), so this effectively says these hosts must be capable of being multi-sited. And I don't think we have a good enough grasp on what the impacts are to support multi-sited hosts. Not to mention the problem Brian raises above on having different defaults based on whether a node is a host or a router - the site-local scope zone IDs will change as IP forwarding is enabled or disabled. Since the scope zone ID is part of the sockaddr structure and is needed to identify the remote partner when using non-global addresses, this could (and very well may) result in loss of connectivity for active connections. Assuming that the use of site-local addresses is not restricted to sites which are not connected to the global internet or other sites (which is my preference), what I'd like to see is this (or another) WG define exactly what support is needed to make this work. This includes standards to define what a site boundary router needs to implement, including updates to routing protocols and the forwarding logic as defined in the scoped addressing architecture. It should also include a BCP which defines application impacts associated with using site-local addresses in these environments and gives guidance on how to work around the problems. For hosts, we should indicate that the current standards only specify how a single-sited host should behave, and multi-sited host support is undefined pending possible future standards work. But lets stop trying to define the default site-local scope zone configuration for hosts and routers. If a router can act as a site boundary router, the router vendor can decide the appropriate default configuration for their product, and whether certain interfaces should be in the same site-local scope zone or in different site-local scope zones by default. 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 Wed Oct 30 12:23:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKNJ29012726; Wed, 30 Oct 2002 12:23:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UKNIuj012725; Wed, 30 Oct 2002 12:23:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKNF29012718 for ; Wed, 30 Oct 2002 12:23:15 -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 g9UKNNMq014168 for ; Wed, 30 Oct 2002 12:23:23 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17093 for ; Wed, 30 Oct 2002 13:23:17 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 12:23:16 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3DA@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAIFU1e6TMiq66RsOEKCF49l/aiwAMPHkg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UKNG29012719 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > If you can compromise the edge router and change its > configuration, you can get either intra-site global > or site-local traffic to be forwarded outside of the > site. Oh really? Maybe you can explain us how you would do that? Let's see, by announcing FE80::/10 or FEC0::/10 to the peers. Problem is, most of them are not that dumb and will filter it. Or maybe, you have a special version of IOS that has IPv6 NAT in it so it enables the host with a link-local address to communicate with the outside. So Margaret, tell us: How do you reconfigure a router to forward site-local traffic to the outside? 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 Oct 30 12:32:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKW829012875; Wed, 30 Oct 2002 12:32:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UKW8qL012874; Wed, 30 Oct 2002 12:32:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKW429012867 for ; Wed, 30 Oct 2002 12:32:04 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00683; Wed, 30 Oct 2002 15:32:11 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9UKWBrL011766; Wed, 30 Oct 2002 15:32:11 -0500 (EST) Message-Id: <200210302032.g9UKWBrL011766@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Wed, 30 Oct 2002 12:23:16 PST." <2B81403386729140A3A899A8B39B046405E3DA@server2000> Reply-to: sommerfeld@east.sun.com Date: Wed, 30 Oct 2002 15:32:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... How do you reconfigure a router to forward > site-local traffic to the outside? create a tunnel. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 12:33:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKXs29012914; Wed, 30 Oct 2002 12:33:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UKXsWd012913; Wed, 30 Oct 2002 12:33:54 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKXp29012906 for ; Wed, 30 Oct 2002 12:33:51 -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 g9UKXwMq021366 for ; Wed, 30 Oct 2002 12:33:59 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07403 for ; Wed, 30 Oct 2002 13:33:52 -0700 (MST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-506.cisco.com [10.82.225.250]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28389; Wed, 30 Oct 2002 15:33:45 -0500 (EST) Message-Id: <4.3.2.7.2.20021030153205.03c5ebd0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Oct 2002 15:33:43 -0500 To: "Michel Py" From: Ralph Droms Subject: RE: Limiting the Use of Site-Local Cc: "Margaret Wasserman" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3DA@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Would you please check your sarcasm at the door? Presumably, if this is a router that can be used either internally or at the edge of a network, it can be configured so that all of its interfaces are part of the same site (so that it forwards site-locals) or that some of its interfaces are not part of the site (so that it doesn't forward site locals). - Ralph Droms At 12:23 PM 10/30/2002 -0800, Michel Py wrote: > > Margaret Wasserman wrote: > > If you can compromise the edge router and change its > > configuration, you can get either intra-site global > > or site-local traffic to be forwarded outside of the > > site. > >Oh really? Maybe you can explain us how you would do that? > >Let's see, by announcing FE80::/10 or FEC0::/10 to the peers. Problem >is, most of them are not that dumb and will filter it. > >Or maybe, you have a special version of IOS that has IPv6 NAT in it so >it enables the host with a link-local address to communicate with the >outside. > >So Margaret, tell us: How do you reconfigure a router to forward >site-local traffic to the outside? > >Michel. > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 12:50:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKo829013134; Wed, 30 Oct 2002 12:50:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UKo85b013133; Wed, 30 Oct 2002 12:50:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UKo429013123 for ; Wed, 30 Oct 2002 12:50:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UKo4Mq025702 for ; Wed, 30 Oct 2002 12:50:05 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13410 for ; Wed, 30 Oct 2002 13:49:59 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UKnsKV024320; Wed, 30 Oct 2002 21:49:54 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 21:49:53 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C46@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'sommerfeld@east.sun.com'" , Michel Py Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 21:49:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... How do you reconfigure a router to forward > > site-local traffic to the outside? > > create a tunnel. => I guess you would give the same answer for link-locals and many other cases. So, if you have a tunnel, secure it. We've had the exacrt same problems with MIPv6. These are not specific to site-locals. Hesham > > - Bill > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 30 13:01:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL1329013268; Wed, 30 Oct 2002 13:01:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UL12Q8013267; Wed, 30 Oct 2002 13:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL0x29013260 for ; Wed, 30 Oct 2002 13:00:59 -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 g9UL17Mq028899 for ; Wed, 30 Oct 2002 13:01:07 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21919 for ; Wed, 30 Oct 2002 14:01:02 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 13:01:06 -0800 Reply-To: From: "Tony Hain" To: "'Tim Hartrick'" , , Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 13:00:43 -0800 Message-ID: <080d01c28057$6962fc00$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210300040.QAA18663@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you! > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tim Hartrick > Sent: Tuesday, October 29, 2002 4:41 PM > To: ipng@sunroof.eng.sun.com; richdr@microsoft.com > Subject: RE: Limiting the Use of Site-Local > > > > > All, > > I generally agree with all the points that Richard Draves has > made. I am not as sanguine about the ease of implementation > in the network stack but there is nothing in the details > which is unimaginably difficult. We very much need to move > on. By my count this is the forth or fifth time this topic > has been debated and redebated. Each time the result has > been the same. If every decision taken by this working group > can be opened repeatedly by a noisy minority then forward > progress of any sort will not be possible. Consensus does > not require unanimity. No matter how noisy and persistent > the minority happens to be, it is possible to move on. > > There are a couple of other points I would like to make. > > Some folks seem to be operating under a misconception about > RFC 1918. RFC 1918 was a response to the rampant use of > arbitrary IPv4 prefixes as private address space. The use of > private address space was not a response to the publishing of > RFC 1918. Network administrators will use "private" IPv6 > address space whether we excise all mention of site-local > addresses from the specifications or not. The network > administrators that use private address space may be stupid, > misinformed or have any number of socially unacceptable > habits but they still run their networks and will run their > networks the way they see fit. Removing site-local addresses > from the architecture or attempting to restrict their use in > a way that is equivalent to removing them is an exercise in > futility absent better alternatives to site-local addresses. > > The burden on those that want to remove site-local addresses > is to provide network administrators with an alternative > which meets their needs but doesn't possess the negative > aspects of site-local addresses that are being railed > against. The requirements that network adminstrators would > place on these addresses would probably be that there is no > registration required and that the addresses are not globally > routable. If such a proposal has been made and it has made > it through last call of this working group, I must have > missed it. Contrary to what has been said by some in the > anti-site-local camp, the burden should be on them to come up > with alternatives to site-local addresses. Until those > alternatives have been thoroughly vetted by this working > group the previous consensus should hold. > > Counter to what one might believe from reading my comments > above, I don't like the architectural mess that has occured > as a consequence of the use private addresses in IPv4. The > difference between me and the anti-site- local camp is that I > don't anticipate that network administrators will stop using > private address (IPv6 or IPv4) unless they are provided with > good reasons not to use them. That means solving > renumbering, solving address shortage, artificial or > otherwise, providing the an alternative "private" address > scheme of the sort cited above and providing the great IPv6 > applications which their customers want but that break in the > presence of site-local addresses. If these things are done, > it won't be necessary to add a bunch of MUST NOTs into the > verbiage in various specifications. Site-local addresses and > all the associated problems will fall into the dustbin of > obsolescence. Absent these things, all the MUST NOTs in the > world won't prevent the use of site-local addresses or some > other form of IPv6 "private" address. > > Network administrators don't read RFCs for the MUST NOTs. > They read them for the solutions they provide. If the MUST > NOTs get in the way of the solution then they get ignored. > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:04:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL4E29013318; Wed, 30 Oct 2002 13:04:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UL4E76013317; Wed, 30 Oct 2002 13:04:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL4B29013310 for ; Wed, 30 Oct 2002 13:04:11 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07099; Wed, 30 Oct 2002 16:04:14 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9UL4DrL013969; Wed, 30 Oct 2002 16:04:13 -0500 (EST) Message-Id: <200210302104.g9UL4DrL013969@thunk.east.sun.com> From: Bill Sommerfeld To: "Hesham Soliman (EAB)" cc: "'sommerfeld@east.sun.com'" , Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Wed, 30 Oct 2002 21:49:49 +0100." <4DA6EA82906FD511BE2F00508BCF0538044F0C46@Esealnt861.al.sw.ericsson.se> Reply-to: sommerfeld@east.sun.com Date: Wed, 30 Oct 2002 16:04:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > create a tunnel. > > => I guess you would give the same answer > for link-locals and many other cases. link-locals are there for autoconfiguration, not security. > So, if you have a tunnel, secure it. answer is non-responsive. we were discussing unauthorized router modifications. site locals do not result in a meaningful improvement in security to a site of nontrivial size -- any node with a global address may unilaterally "choose" to extend the site... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:08:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL8B29013385; Wed, 30 Oct 2002 13:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UL8Bn3013384; Wed, 30 Oct 2002 13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UL8729013374 for ; Wed, 30 Oct 2002 13:08:07 -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 g9UL8FMq000960 for ; Wed, 30 Oct 2002 13:08:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17289 for ; Wed, 30 Oct 2002 13:08:09 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UL88005516; Wed, 30 Oct 2002 16:08:08 -0500 (EST) Message-Id: <200210302108.g9UL88005516@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian Haberman cc: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Wed, 30 Oct 2002 13:45:53 EST.") <3DC028E1.4060605@nc.rr.com> Date: Wed, 30 Oct 2002 16:08:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What are others' opinions on this issue? I'm actually thinking that the most desirable default behavior for routers is one that discourages use of SLs unless they're explicitly configured. So I am inclined to believe that a router (or a multi-interface host when acting as a router) should by default treat every interface as if it were in a separate site, and therefore refuse to forward SLs at all. to enable SLs at a router the admin should have to label *each* separate interface with a site-id. similarly, hosts should not configure SLs by default. that way, in the absence of any configuration, SLs simply don't work at all. apps on correctly-configured hosts aren't exposed to them because they aren't configured on any of their interfaces. if any host does try to send packets to them, or source packets from them, they don't get past the first router. this also seems to produce the "right" behavior for people who believe that SLs provide some security - default policy is to deny all SL traffic, then you can explicitly decide when to permit it. I also think it produces the most desirable end-state should we reach consensus to deprecate/discourage SLs - if routers discourage SL by default then they'll continue to do the right thing by default when it's generally realized that they were a bad idea anyway, and they'll continue to be backward compatible for those who invested in them. Keith p.s. actually I believe that routers should refuse to forward SLs if they know of any route to any routable prefix, in order to enforce the restriction that SLs should not be used except on isolated networks. so the above could be considered a fallback position. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:11:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULB729013456; Wed, 30 Oct 2002 13:11:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULB7j0013455; Wed, 30 Oct 2002 13:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULB329013448 for ; Wed, 30 Oct 2002 13:11:03 -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 g9ULBBbB006479 for ; Wed, 30 Oct 2002 13:11:11 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26008 for ; Wed, 30 Oct 2002 14:11:05 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 13:11:05 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD284@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAU4xCSnE2/rQzS1WVVJMCYhRDOAABUFCQ From: "Michel Py" To: Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULB429013449 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> ... How do you reconfigure a router to forward >> site-local traffic to the outside? > Bill Sommerfeld wrote: > create a tunnel. Good idea. Trouble is, the tunneling protocol is blocked by the firewall. What's your next move? (You don't expect to find a router that is connected to a secure network being a sitting duck on the Internet not being protected by a firewall, do you?) 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 Oct 30 13:14:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULE629013512; Wed, 30 Oct 2002 13:14:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULE60a013511; Wed, 30 Oct 2002 13:14:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULE229013503 for ; Wed, 30 Oct 2002 13:14:02 -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 g9ULEAbB007231 for ; Wed, 30 Oct 2002 13:14:10 -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 OAA29071 for ; Wed, 30 Oct 2002 14:14:04 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA05860; Wed, 30 Oct 2002 13:13:55 -0800 (PST) Message-Id: <5.1.0.14.2.20021030160935.029fa780@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:15:12 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E3DA@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:23 PM 10/30/02, Michel Py wrote: > > Margaret Wasserman wrote: > > If you can compromise the edge router and change its > > configuration, you can get either intra-site global > > or site-local traffic to be forwarded outside of the > > site. > >Oh really? Maybe you can explain us how you would do that? > >Let's see, by announcing FE80::/10 or FEC0::/10 to the peers. Problem >is, most of them are not that dumb and will filter it. > >Or maybe, you have a special version of IOS that has IPv6 NAT in it so >it enables the host with a link-local address to communicate with the >outside. > >So Margaret, tell us: How do you reconfigure a router to forward >site-local traffic to the outside? It depends what you mean by the "outside". If I am on a link that is attached to the SBR, but in another site, I could reconfigure the router to consider my link as part of the site. If I am further away from the router, I could possibly configure the router to tunnel site-local traffic across the underlying (v4 or v6) network. Let me turn the question around... You have posited that the use of site-local address is somehow more "secure" than using a private global address range that is filtered in the router. Why? What attacks would work in the latter case that wouldn't work in the former case? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:14:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULEu29013555; Wed, 30 Oct 2002 13:14:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULEus4013554; Wed, 30 Oct 2002 13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULEq29013544 for ; Wed, 30 Oct 2002 13:14:52 -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 g9ULF0bB007487 for ; Wed, 30 Oct 2002 13:15:00 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29522 for ; Wed, 30 Oct 2002 14:14:53 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 13:14:58 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: Default site-local behavior for routers Date: Wed, 30 Oct 2002 13:14:35 -0800 Message-ID: <080e01c28059$59318f20$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DC028E1.4060605@nc.rr.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULEq29013545 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The whole discussion about lack of definition of site boundary is bogus, and causing a large waste of energy. We don't tell people how to bound areas in OSPF, yet we are expected to spell out the universal definition of a site. To a first order, the concepts are exactly the same, how much information is exposed across administrative borders. An organization should probably start with the assumption that a site boundary is exactly congruent with an OSPF area, but they may choose to restrict it further, or expand it when it makes sense for their network. In any case, the site boundary should never be larger than the IGP scope, so if we are going to talk about defaults, rather than assuming every interface is in a different site, why not assume every EGP/IGP boundary identifies a different site? If we can get past that, maybe we can start talking about area boundaries as a reasonable default. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Brian Haberman > Sent: Wednesday, October 30, 2002 10:46 AM > To: ipng@sunroof.eng.sun.com > Subject: Default site-local behavior for routers > > > So, one of the items that Margaret suggested was some text in > the node requirements doc or the scoped addr arch that states > that nodes default to being in one site. > > However, there has been some mention that people would prefer > different behavior in routers. That is, the stated desire > was that, by default, each interface on a router be in its own site. > > This suggestion leads to the model where hosts with multiple > interfaces will assume that all its interfaces are in the > same site (e.g. have the same site-local zone id) unless > explicitly configured to have multiple sites. While routers > will default to having a unique site-local zone id for each > interface (thus rendering SLs to link-local behavior) unless > explicitly configured to have multiple interfaces in the same site. > > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. > > What are others' opinions on this issue? > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:17:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULHC29013657; Wed, 30 Oct 2002 13:17:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULHBhw013656; Wed, 30 Oct 2002 13:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULH829013640 for ; Wed, 30 Oct 2002 13:17:08 -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 g9ULH1bB008117 for ; Wed, 30 Oct 2002 13:17:01 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22161 for ; Wed, 30 Oct 2002 14:16:55 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9ULGpQ1029982; Wed, 30 Oct 2002 22:16:51 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 22:16:51 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C48@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'sommerfeld@east.sun.com'" Cc: Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 22:16:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => I guess you would give the same answer > > for link-locals and many other cases. > > link-locals are there for autoconfiguration, not security. => You said that if you want forward site-locals beyond a site then create a tunnel and I said: I guess you would give the same answer > > for link-locals and many other cases. I didn't say anything about site-locals and security and I didn't ask what link-locals are for. I said that you can create a tunnel to take link-locals beyond a link, so the problem is not specific to site-locals. > > > So, if you have a tunnel, secure it. > > answer is non-responsive. we were discussing unauthorized > router modifications. => It's responding to the comment that site-locals can be forwarded beyond the site if a tunnel is created. > > site locals do not result in a meaningful improvement in > security to a > site of nontrivial size -- any node with a global address may > unilaterally "choose" to extend the site... => I was not debating this point. But I agree that if a node inside the side wishes to extend it, it can do that. It can also do that if it tunnels IP packets in HTTP. So this is a different scenario (having a "malicious" node inside the site). Hesham > > - Bill > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:21:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULLA29013771; Wed, 30 Oct 2002 13:21:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULLA1k013770; Wed, 30 Oct 2002 13:21:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULL629013757 for ; Wed, 30 Oct 2002 13:21:06 -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 g9ULLEbB009525 for ; Wed, 30 Oct 2002 13:21:14 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24880; Wed, 30 Oct 2002 14:21:08 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA10610; Wed, 30 Oct 2002 13:20:57 -0800 (PST) Message-Id: <5.1.0.14.2.20021030161904.07aefb30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:22:21 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'sommerfeld@east.sun.com'" , Michel Py , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C48@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I didn't say anything about site-locals and security >and I didn't ask what link-locals are for. I said >that you can create a tunnel to take link-locals >beyond a link, so the problem is not specific to >site-locals. Actually, I think that there are some important differences between link-locals and site-locals. A router might (and probably should) be hard-coded not to forward link-local packets, as there is no reason to ever forward them. However, a router that might ever need have multiple interfaces in a single site can't be hard-coded not to forward site-locals. Whether or not they will be forwarded is the result of configuration. There is another important difference that doesn't relate directly to security (as far as I know): site-local prefixes are advertised by routers, and they differ from link to link (different subnet IDs), whereas the link-local prefix is a single constant. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:24:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULOa29013861; Wed, 30 Oct 2002 13:24:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULOaSB013860; Wed, 30 Oct 2002 13:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULOX29013853 for ; Wed, 30 Oct 2002 13:24:33 -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 g9ULOfbB010457 for ; Wed, 30 Oct 2002 13:24:41 -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 OAA05350 for ; Wed, 30 Oct 2002 14:24:35 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA14329; Wed, 30 Oct 2002 13:24:24 -0800 (PST) Message-Id: <5.1.0.14.2.20021030162312.01a67130@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:25:15 -0500 To: From: Margaret Wasserman Subject: RE: Default site-local behavior for routers Cc: In-Reply-To: <080e01c28059$59318f20$4b194104@eagleswings> References: <3DC028E1.4060605@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >An organization should probably start with the assumption that a site >boundary is exactly congruent with an OSPF area, but they may choose to >restrict it further, or expand it when it makes sense for their network. >In any case, the site boundary should never be larger than the IGP >scope, so if we are going to talk about defaults, rather than assuming >every interface is in a different site, why not assume every EGP/IGP >boundary identifies a different site? If we can get past that, maybe we >can start talking about area boundaries as a reasonable default. Actually, there has been some discussion amongst various routing-related folks that has led to the belief that a site must always be congruent with a single OSPF or IS-IS area. This is necessary in order to meet the "convexity" requirement for sites with respect to both site-local and global addressing. I've had an action item for a while to summarize the thread that led to this conclusion to the IPv6 list, but I haven't gotten to it yet. I'll do so soon. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:24:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULOs29013880; Wed, 30 Oct 2002 13:24:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULOsnP013879; Wed, 30 Oct 2002 13:24:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULOn29013870 for ; Wed, 30 Oct 2002 13:24:49 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10669; Wed, 30 Oct 2002 16:24:54 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9ULOrrL014378; Wed, 30 Oct 2002 16:24:53 -0500 (EST) Message-Id: <200210302124.g9ULOrrL014378@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Wed, 30 Oct 2002 13:11:05 PST." <2B81403386729140A3A899A8B39B04640BD284@server2000> Reply-to: sommerfeld@east.sun.com Date: Wed, 30 Oct 2002 16:24:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Good idea. Trouble is, the tunneling protocol is blocked by the > firewall. What's your next move? what *does* the firewall allow through? if the answer is "nothing", we've reduced this to the "no external connectivity case" and you can save a bunch of money by simply removing the firewall and auctioning it on eBay. If the answer is "protocol X", I just need to find a way to tunnel IP datagrams inside protocol X. I've seen worked examples using DNS, http, ssh, smtp, ... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:27:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULRD29013957; Wed, 30 Oct 2002 13:27:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULRCoV013956; Wed, 30 Oct 2002 13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULR929013949 for ; Wed, 30 Oct 2002 13:27:09 -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 g9ULRHMq006269 for ; Wed, 30 Oct 2002 13:27:17 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26555 for ; Wed, 30 Oct 2002 14:27:12 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:27:14 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 13:27:11 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:27:11 -0800 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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 13:27:11 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/lZJBFEUIgUByRa6wDgAXPo+mbQAw9Iiw From: "Richard Draves" To: "Keith Moore" Cc: X-OriginalArrivalTime: 30 Oct 2002 21:27:11.0285 (UTC) FILETIME=[1B93DE50:01C2805B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULRA29013950 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > or to put it another way, why do you have so much faith in > filters of SL addresses and so little faith in filters of prefixes? Your "so much faith" and "so little faith" are exaggerating my position. But I do think that site-local addresses will offer better security in practice than filtering a global prefix. Why is that? First, the security of the site-local addresses rests on proper configuration of the site boundaries. I think this is easier to get right and maintain than filters of a global prefix. It's simpler conceptually. For example when a site renumbers, any filters of the changing global prefix would have to be updated. Any mistakes in this process would not be immediately obvious. Also the configuration of the site boundaries can be handled automatically in some circumstances. For example Microsoft's ICS product (a firewall) automatically puts the interfaces on the inside & outside of the firewall into different sites. Second, there is "defense in depth" of the site-local prefix. Suppose an administrator does screwup the configuration of a boundary router. In practice there will be additional site boundaries between an attacker and the misconfigured router. I expect transit routers in the internet backbone would filter site-locals. So the attacker will still not have access to the site via site-locals. 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 Wed Oct 30 13:27:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULRc29013991; Wed, 30 Oct 2002 13:27:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULRcbY013989; Wed, 30 Oct 2002 13:27:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULRV29013976 for ; Wed, 30 Oct 2002 13:27:31 -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 g9ULRdbB011297 for ; Wed, 30 Oct 2002 13:27:39 -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 NAA01322 for ; Wed, 30 Oct 2002 13:27:33 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 13:27:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD285@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAWu/9E8Yk1E9SSfOtw/coyExwSQAABBlQ From: "Michel Py" To: Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULRV29013979 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the answer is "protocol X", I just need to find a > way to tunnel IP datagrams inside protocol X. I've > seen worked examples using DNS, http, ssh, smtp, Back to my original post: do you have the IOS image that can create http tunnels on a Cisco 12000? 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 Oct 30 13:27:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULRc29013992; Wed, 30 Oct 2002 13:27:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULRcCo013990; Wed, 30 Oct 2002 13:27:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULRV29013975 for ; Wed, 30 Oct 2002 13:27:31 -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 g9ULRdbB011296 for ; Wed, 30 Oct 2002 13:27:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01312 for ; Wed, 30 Oct 2002 13:27:33 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9ULRSKV027583; Wed, 30 Oct 2002 22:27:28 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 22:27:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C49@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" Cc: "'sommerfeld@east.sun.com'" , Michel Py , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 22:27:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > >I didn't say anything about site-locals and security > >and I didn't ask what link-locals are for. I said > >that you can create a tunnel to take link-locals > >beyond a link, so the problem is not specific to > >site-locals. > > Actually, I think that there are some important differences > between link-locals and site-locals. => I hereby declare to the ML that I completely agree that link-locals and site-locals are different :) The point was: using tunnelling to evade scope boundaries. This can be done in a zillion ways for different addresses, if we're not careful how the tunnel is setup or if a malicious node is inside the site and can fool the firewall (if one exists). Just making sure that we're talking about the same thing. Hesham > > A router might (and probably should) be hard-coded not to > forward link-local packets, as there is no reason to ever > forward them. > > However, a router that might ever need have multiple interfaces > in a single site can't be hard-coded not to forward site-locals. > Whether or not they will be forwarded is the result of > configuration. > > There is another important difference that doesn't relate > directly to security (as far as I know): site-local prefixes > are advertised by routers, and they differ from link to link > (different subnet IDs), whereas the link-local prefix is a > single constant. > > Margaret > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:33:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULXi29014277; Wed, 30 Oct 2002 13:33:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULXhsq014276; Wed, 30 Oct 2002 13:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULXd29014269 for ; Wed, 30 Oct 2002 13:33:39 -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 g9ULXlbB013366 for ; Wed, 30 Oct 2002 13:33:47 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00138 for ; Wed, 30 Oct 2002 14:33:42 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:33:41 -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); Wed, 30 Oct 2002 13:33:41 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 13:33:36 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:33:40 -0800 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: Forwarding packets with site-local source [Re: Choices to go forward with SL] Date: Wed, 30 Oct 2002 13:33:38 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Forwarding packets with site-local source [Re: Choices to go forward with SL] Thread-Index: AcJ/tgcoYculvwiDSzOZLGkLzRrTeAApTAyw From: "Richard Draves" To: "Brian Haberman" Cc: X-OriginalArrivalTime: 30 Oct 2002 21:33:40.0805 (UTC) FILETIME=[03BFE750:01C2805C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULXd29014270 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My take is that the two possible router configs for site locals is > > 1. All interfaces are in the same site > 2. All interfaces are in unique sites > > Margaret's proposal that the default behavior is a node's > interfaces are in 1 site results in case 1. For a router, a > safer config may be 2. That would strictly limit the outward > flow of site local addresses. I like the idea the hosts default to all interfaces in one site, and routers default to each interface is in a different site. > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. This is a good question but a) it seems surmountable and b) I don't think the answer needs to be standardized, since changing on the fly between router & host behavior is not standardized. For example suppose that in the absence of configuration, host interfaces use the site id 1. When a host interface is changed to become a router interface, if it has site id 1 then it automatically changes to a new unused site id (eg, one larger than the largest currently in use on the node). When a router interface is changed to a host interface, you leave the site id alone (unless the operator also changes it explicitly of course). 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 Wed Oct 30 13:37:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULbm29014427; Wed, 30 Oct 2002 13:37:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULbmV8014426; Wed, 30 Oct 2002 13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULbj29014416 for ; Wed, 30 Oct 2002 13:37:45 -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 g9ULbrbB014622 for ; Wed, 30 Oct 2002 13:37:53 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05664 for ; Wed, 30 Oct 2002 14:37:47 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA26081; Wed, 30 Oct 2002 13:37:35 -0800 (PST) Message-Id: <5.1.0.14.2.20021030163315.07b24ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:38:48 -0500 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "'sommerfeld@east.sun.com'" , Michel Py , ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C49@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, >=> I hereby declare to the ML that I completely >agree that link-locals and site-locals are different :) :-) Sorry if my note seemed condescending or something... I didn't mean it that way. >The point was: using tunnelling to evade scope boundaries. >This can be done in a zillion ways for different addresses, >if we're not careful how the tunnel is setup or if a malicious >node is inside the site and can fool the firewall (if one exists). I completely agree... The current discussion is (I think) attempting to compare the security implications of two ways of addressing a private network: - Using site-local addresses that are filtered at an SBR due to site configuration. - Using global addresses that are filtered at the border of the private address space using routing filters. In neither case would the addresses being used on the private network appear in global routing tables. I still don't really understand why these cases are substantially different in terms of security... Not that I'm claiming to be a security expert or anything, but I would like to understand what the difference are, if any. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:39:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULdp29014498; Wed, 30 Oct 2002 13:39:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULdpx4014497; Wed, 30 Oct 2002 13:39:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULdm29014490 for ; Wed, 30 Oct 2002 13:39: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 g9ULdtbB015112 for ; Wed, 30 Oct 2002 13:39:56 -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 OAA03593 for ; Wed, 30 Oct 2002 14:39:50 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:39:50 -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); Wed, 30 Oct 2002 13:39:49 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 13:39:45 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 13:39:49 -0800 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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 13:39:46 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAWo5XwDUzfiFYRmGuYQqsyqBRNgAAd9wQ From: "Richard Draves" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 30 Oct 2002 21:39:49.0473 (UTC) FILETIME=[DF7E2D10:01C2805C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULdm29014491 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A router might (and probably should) be hard-coded not to > forward link-local packets, as there is no reason to ever > forward them. > > However, a router that might ever need have multiple > interfaces in a single site can't be hard-coded not to > forward site-locals. Whether or not they will be forwarded is > the result of configuration. Actually, a router can forward link-locals between interfaces on the same link. In particular, a router can forward a packet with link-local dest and/or source back out the interface from which it arrived (and presumably generate a Redirect too). If you are implementing link-locals properly, it's really very little additional code to support site-locals. At least that's my experience. 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 Wed Oct 30 13:46:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULkn29014748; Wed, 30 Oct 2002 13:46:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULknw1014747; Wed, 30 Oct 2002 13:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULkk29014740 for ; Wed, 30 Oct 2002 13:46:46 -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 g9ULksbB017063 for ; Wed, 30 Oct 2002 13:46:54 -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 OAA17080 for ; Wed, 30 Oct 2002 14:46:48 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA01971; Wed, 30 Oct 2002 13:46:36 -0800 (PST) Message-Id: <5.1.0.14.2.20021030164545.07b19670@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:47:58 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Forwarding packets with site-local source [Re: Choices to go forward with SL] Cc: "Brian Haberman" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:33 PM 10/30/02, Richard Draves wrote: > > My take is that the two possible router configs for site locals is > > > > 1. All interfaces are in the same site > > 2. All interfaces are in unique sites > > > > Margaret's proposal that the default behavior is a node's > > interfaces are in 1 site results in case 1. For a router, a > > safer config may be 2. That would strictly limit the outward > > flow of site local addresses. > >I like the idea the hosts default to all interfaces in one site, and >routers default to each interface is in a different site. I have some concerns about this idea, because it means that routers won't work out-of-the-box in a disconnected, multi-network site that is only numbered using site-locals... Also, does it require that all routers will be capable of acting as SBRs? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:47:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULlQ29014787; Wed, 30 Oct 2002 13:47:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULlQqG014786; Wed, 30 Oct 2002 13:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULlL29014772 for ; Wed, 30 Oct 2002 13:47:21 -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 g9ULlTMq012498 for ; Wed, 30 Oct 2002 13:47:29 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09796; Wed, 30 Oct 2002 13:47:23 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9ULlCKV029144; Wed, 30 Oct 2002 22:47:12 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 22:47:12 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C4A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "'sommerfeld@east.sun.com'" , Michel Py , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 22:47:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > :-) > > Sorry if my note seemed condescending or something... I > didn't mean it that way. => oh no I didn't interpret it that way, I just wanted to make sure that we talk about the same thing. > >The point was: using tunnelling to evade scope boundaries. > >This can be done in a zillion ways for different addresses, > >if we're not careful how the tunnel is setup or if a malicious > >node is inside the site and can fool the firewall (if one exists). > > I completely agree... > > The current discussion is (I think) attempting to compare the > security implications of two ways of addressing a private > network: > > - Using site-local addresses that are filtered at > an SBR due to site configuration. > - Using global addresses that are filtered at the > border of the private address space using > routing filters. > > In neither case would the addresses being used on the private > network appear in global routing tables. > > I still don't really understand why these cases are substantially > different in terms of security... => I think that if you put Tony Hain's email together with Rich Draves' last email, you would get a good idea about why it's better and what the "default" should be. I think they both make sense. For a host, I think that the default should be 1 site per interface. Not that I'm claiming to be > a security expert or anything, but I would like to understand > what the difference are, if any. => Sure, I think most of the mails on this thread are clarifying this. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:48:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULmW29014837; Wed, 30 Oct 2002 13:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULmWJ8014836; Wed, 30 Oct 2002 13:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULmQ29014820 for ; Wed, 30 Oct 2002 13:48: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 g9ULmYbB017569 for ; Wed, 30 Oct 2002 13:48:34 -0800 (PST) Received: from starfruit.itojun.org (d224-160.uoregon.edu [128.223.224.160]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10356 for ; Wed, 30 Oct 2002 13:48:29 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B731F7B9; Thu, 31 Oct 2002 06:47:40 +0900 (JST) To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Wed, 30 Oct 2002 13:39:46 PST. 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: Limiting the Use of Site-Local From: Jun-ichiro itojun Hagino Date: Thu, 31 Oct 2002 06:47:40 +0900 Message-Id: <20021030214740.B731F7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> A router might (and probably should) be hard-coded not to >> forward link-local packets, as there is no reason to ever >> forward them. >> >> However, a router that might ever need have multiple >> interfaces in a single site can't be hard-coded not to >> forward site-locals. Whether or not they will be forwarded is >> the result of configuration. > >Actually, a router can forward link-locals between interfaces on the >same link. In particular, a router can forward a packet with link-local >dest and/or source back out the interface from which it arrived (and >presumably generate a Redirect too). > >If you are implementing link-locals properly, it's really very little >additional code to support site-locals. At least that's my experience. could you comment on routing code? (RIPng, OSPFv3) i still think it's way too tough to support multi-sited node. 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 Wed Oct 30 13:49:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULnS29014857; Wed, 30 Oct 2002 13:49:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULnS2u014856; Wed, 30 Oct 2002 13:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULnN29014849 for ; Wed, 30 Oct 2002 13:49:23 -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 g9ULnVbB017874 for ; Wed, 30 Oct 2002 13:49:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10966 for ; Wed, 30 Oct 2002 13:49:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9ULn9005604; Wed, 30 Oct 2002 16:49:09 -0500 (EST) Message-Id: <200210302149.g9ULn9005604@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 13:27:11 PST.") Date: Wed, 30 Oct 2002 16:49:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your "so much faith" and "so little faith" are exaggerating my position. > But I do think that site-local addresses will offer better security in > practice than filtering a global prefix. Why is that? > > First, the security of the site-local addresses rests on proper > configuration of the site boundaries. I think this is easier to get > right and maintain than filters of a global prefix. It's simpler > conceptually. For example when a site renumbers, any filters of the > changing global prefix would have to be updated. when a site renumbers the routers are going to have to be updated anyway. of course we need a solution for this problem. but having site locals won't change the need to reconfigure routers when renumbering. > Second, there is "defense in depth" of the site-local prefix. Suppose an > administrator does screwup the configuration of a boundary router. In > practice there will be additional site boundaries between an attacker > and the misconfigured router. the same kind of defense in depth is possible (and quite reasonable) with prefix filtering - and it's more flexible since it doesn't require the same prefix length to be filtered at each router. > I expect transit routers in the internet > backbone would filter site-locals. So the attacker will still not have > access to the site via site-locals. I agree that SLs would not get very far in the public Internet. that doesn't mean that they wouldn't leak at all, but attacks using SLs would probably have to be mounted from "near" the site being attacked. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:50:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULoU29014888; Wed, 30 Oct 2002 13:50:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULoUZP014887; Wed, 30 Oct 2002 13:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULoP29014880 for ; Wed, 30 Oct 2002 13:50: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 g9ULoXMq013364 for ; Wed, 30 Oct 2002 13:50:33 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15475; Wed, 30 Oct 2002 13:50:27 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9ULoN005664; Wed, 30 Oct 2002 16:50:24 -0500 (EST) Message-Id: <200210302150.g9ULoN005664@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'sommerfeld@east.sun.com'" , Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 21:49:49 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C46@Esealnt861.al.sw.ericsson.se> Date: Wed, 30 Oct 2002 16:50:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > ... How do you reconfigure a router to forward > > > site-local traffic to the outside? > > > > create a tunnel. > > => I guess you would give the same answer > for link-locals and many other cases. > So, if you have a tunnel, secure it. > We've had the exacrt same problems with > MIPv6. These are not specific to site-locals. I think the point is that SLs aren't more immune to security problems than globals. If you can tweak the router configuration you can find a way to route them off-site. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:51:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULpI29014927; Wed, 30 Oct 2002 13:51:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULpIom014926; Wed, 30 Oct 2002 13:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULpE29014919 for ; Wed, 30 Oct 2002 13:51:14 -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 g9ULpLbB018518 for ; Wed, 30 Oct 2002 13:51:21 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14909 for ; Wed, 30 Oct 2002 14:51:15 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9ULpDKV029450; Wed, 30 Oct 2002 22:51:13 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 22:51:07 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C4B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Richard Draves'" , Brian Haberman Cc: ipng@sunroof.eng.sun.com Subject: RE: Forwarding packets with site-local source [Re: Choices to go forward with SL] Date: Wed, 30 Oct 2002 22:51:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I like the idea the hosts default to all interfaces in one site, => I think this will be a problem for mobile hosts. Using ND alone you can't know if both interfaces are in the same site. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:51:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULpS29014940; Wed, 30 Oct 2002 13:51:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULpSFq014939; Wed, 30 Oct 2002 13:51:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULpM29014932 for ; Wed, 30 Oct 2002 13:51:23 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15241; Wed, 30 Oct 2002 16:51:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9ULpTrL014722; Wed, 30 Oct 2002 16:51:29 -0500 (EST) Message-Id: <200210302151.g9ULpTrL014722@thunk.east.sun.com> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: Your message of "Wed, 30 Oct 2002 13:27:33 PST." <2B81403386729140A3A899A8B39B04640BD285@server2000> Reply-to: sommerfeld@east.sun.com Date: Wed, 30 Oct 2002 16:51:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Back to my original post: do you have the IOS image that can create http > tunnels on a Cisco 12000? Why should I believe that a sufficiently determined adversary couldn't somehow obtain a bootleg copy of IOS source? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:53:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULqx29015026; Wed, 30 Oct 2002 13:52:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULqxkR015024; Wed, 30 Oct 2002 13:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULqu29015014 for ; Wed, 30 Oct 2002 13:52: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 g9ULr4Mq014119 for ; Wed, 30 Oct 2002 13:53:04 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13077 for ; Wed, 30 Oct 2002 13:52:58 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA06621; Wed, 30 Oct 2002 13:52:50 -0800 (PST) Message-Id: <5.1.0.14.2.20021030164823.00a95080@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 16:53:35 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local 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 > >Actually, a router can forward link-locals between interfaces on the >same link. In particular, a router can forward a packet with link-local >dest and/or source back out the interface from which it arrived (and >presumably generate a Redirect too). Good point. >If you are implementing link-locals properly, it's really very little >additional code to support site-locals. At least that's my experience. I agree that, in terms of _stack_ complexity, site-locals don't add much. The additional complexity comes at other layers -- routing protocols, DNS, applications, transport protocols, management apps, etc. Some of these complexities don't apply to link-local addresses, because no one expects to put them in the DNS, exchange them in routing protocols, or use them in upper layer protocols, except as a last resort (when the single link _is_ the entire network). I am essentially suggesting that we treat site-locals the same way -- use them only as a last resort when the site _is_ the entire network. Link locals already cause problems for management protocols. For example, it won't be possible, using the IP address of a BGP peer from the MIB (which will be link-local), for a management station on another link to find that host and communicate with it... So, it probably would have been better to use global addresses for routing protocols and limit their hop count to 1. Oh, well. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 13:58:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULwu29015295; Wed, 30 Oct 2002 13:58:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9ULwuGx015294; Wed, 30 Oct 2002 13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9ULwr29015287 for ; Wed, 30 Oct 2002 13:58: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 g9ULx1Mq015653 for ; Wed, 30 Oct 2002 13:59:01 -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 NAA16212 for ; Wed, 30 Oct 2002 13:58:55 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 13:58:55 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD286@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAXqFiVi/RfZnVQQm4Yc0qFz61XgAAD0eA From: "Michel Py" To: Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9ULwr29015288 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why should I believe that a sufficiently determined > adversary couldn't somehow obtain a bootleg copy of > IOS source? So tell me which of the following setups is the most secure: a) The one that requires, in order to be hacked, to get a bootleg copy of the IOS source, all the tools needed to compile it, understand how it works, be able to modify the code... b) The one that does not? 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 Oct 30 14:02:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UM2c29015444; Wed, 30 Oct 2002 14:02:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UM2baR015443; Wed, 30 Oct 2002 14:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UM2Y29015433 for ; Wed, 30 Oct 2002 14:02:34 -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 g9UM2gMq017104 for ; Wed, 30 Oct 2002 14:02:42 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22481 for ; Wed, 30 Oct 2002 15:02:36 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 14:02:35 -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); Wed, 30 Oct 2002 14:02:35 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 14:02:37 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 14:02:34 -0800 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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 14:02:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAXjELuJKqgCBjTZ6ZKH6ErlwbIwAAUspQ From: "Richard Draves" To: "Keith Moore" Cc: X-OriginalArrivalTime: 30 Oct 2002 22:02:34.0645 (UTC) FILETIME=[0D32E450:01C28060] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UM2Y29015434 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > when a site renumbers the routers are going to have to be updated > anyway. of course we need a solution for this problem. but > having site locals won't change the need to reconfigure > routers when renumbering. You haven't contested my point that the security based on site-locals will not be comprised when a site renumbers, whereas security based on the filtering of a global prefix is vulnerable to mishap during renumbering. So I take it you agree that site-locals do offer an advantage here? > > Second, there is "defense in depth" of the site-local > prefix. Suppose > > an administrator does screwup the configuration of a > boundary router. > > In practice there will be additional site boundaries between an > > attacker and the misconfigured router. > > the same kind of defense in depth is possible (and quite reasonable) > with prefix filtering - and it's more flexible since it > doesn't require > the same prefix length to be filtered at each router. I don't understand this. In your proposal, every site will be filtering a different global prefix. Routers in the internet backbone will not be filtering any global prefix. Where is the comparable defense in the depth? 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 Wed Oct 30 14:16:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMG329015807; Wed, 30 Oct 2002 14:16:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMG2ol015806; Wed, 30 Oct 2002 14:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMFx29015799 for ; Wed, 30 Oct 2002 14:15:59 -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 g9UMG7bB026244 for ; Wed, 30 Oct 2002 14:16:07 -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 PAA04860 for ; Wed, 30 Oct 2002 15:15:59 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA16413; Wed, 30 Oct 2002 17:15:54 -0500 (EST) Date: Wed, 30 Oct 2002 17:15:54 -0500 (EST) From: Dan Lanciani Message-Id: <200210302215.RAA16413@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "sasson, shuki" wrote: |Hi all, indeed scoping is a pain... specifically since it is not carried as |a part of the address. |In any case we should give an escape path out of this ambiguity to a "known" |world. |Meaning if a node is configured with a global addresses the global addresses |will have higher priority being used as a source address over SL. That's certainly not the behavior I would want. If I go to the trouble of configuring my systems with stable site-local addresses I want to use those addresses where possible so as to be independent of the renumbering whims of my ISP. Margaret Wasserman wrote: |What do stack and application vendors need to do to support site-local |addressing? A more relevant question might be, ``what do stack and application vendors have to do to support multiple concurrent addressing scopes including global and site-local?'' If you are suggesting that the answer is that they don't have to do anything special then why do you feel the need to restrict site- local address usage? |And what makes you think that they are doing those things now? Did I say that I thought they were doing those things now? I'm not even convinced that an IPv6 application market exists yet. When and if such a market exists I would prefer that the products support some notion of stable local addresses. Currently site-local addresses--and the associated hack that is scopes--serve this purpose. Without such support the only alternative will be NAT. |The majority of stack and application implementations with which I am |familiar make no distinction at all between site-local address and |globals. So are you saying that essentially nobody deals with scopes in a useful way? That's unfortunate, but it isn't too late to improve the situation. |This is appropriate if site-locals will be used only on non-globally |connected sites (so, effectively, site-local == global). This eliminates the problem by eliminating site-local addresses as a unique scope. That in turn pretty much gets rid of scopes since link-local was already a special case that most higher-level code doesn't care about. I've always been in favor of global addresses and I would happily trade stable site-locals for stable globals. Where can I get some? Note that if we are talking about globally unique non-routable addresses it may not eliminate the need for scopes. But it's certainly a step in the right direction. "Michel Py" wrote: |Now, explain me how you design that network (the plane) with deprecating |site-locals when global addresses are present. Modern plane designs are |multiple redundant networks that carry data for almost all of the |plane's devices. Presumably you are supposed to get a global address for the rudder controller and hope that the FAA implements a no-renumbering-in-flight rule. The rest of us with less critical applications will probably just have to make do with unstable addresses. The thing that bothers me about this discussion is that it is starting to sound as if site-local addressing (and all the endless debate about scope and address selection rules) was just another sham like transparent renumbering. Until a few days ago site-local addresses (along with the scope baggage they entail) were a part of the IPv6 vision. Now suddenly they are a minor wart to be eliminated, and all roads seem to lead back to the situation where the stability (and cost) of your internal network is directly dependent on your ISP. This in turn will almost certainly result in the introduction of IPv6 NAT and we will be right back where we started. Margaret Wasserman wrote: |Seriously, we have an opportunity, with the introduction of |IPv6, to advocate new ways of doing things on the new |network. | |Just because people have been doing something one (bad) way |in the past, doesn't mean that we should advocate that |approach in IPv6. Wow. I think I used almost exactly those words a few years back in a futile argument for global portable identifiers. But you seem to be advocating constraining v6's addressing to work just as v4's does. How is that new? One of the (IMHO, very few) benefits of the v6 addressing architecture is that scoped site-local addresses allow some of the desirable functionality of NAT and private addressing to integrate smoothly. I'm not saying that this was a good tradeoff. I would have preferred to see work on the routing problem so that everybody could have their own stable routable addresses. But that would have upset the status quo a bit too much and we got scopes instead. The bottom line is that by hand-waving arguments scoped addressing was declared feasible while routing portable addresses was declared impossible. The bed has been made and now we have to lie in it... "Bound, Jim" wrote: |Dan, | |This is quite a good commentary. What you say is exactly what will |happen too in the commercial deployment of IPv6 (as opposed to AD, |research, and non fully supported product where the vendor states you |can use this in your production network). | |But I have heard this TCP long lived connection discussion for a long |time. Lets discuss. The address stability issue goes way beyond persistent tcp connections. It has been discussed extensively in the past. I'm not interested in trying to falsely reduce the entire issue to a single straw man which can be conveniently dismissed as unimportant (or tabled until some great new protocol solves the problem). |But first anyone who believes they have the right |to keep telnet up 24 hours a day across global networks is sadly |mistaken and that's just crazy and lets evil security bad people really |get to test their skill out. Security by short-lived connections? I hope this is a joke... |I know of a user who has to have long lived TCP connections in mission |critical situation and wants to do it with IPv6. I have advised them to |NOT use SLs. Here is why. The user implementation will have user |internal routers across the site (properly defined). |But people in the site will and must have access out of the site and |that is why we have that problem long discussed here in reality from a |few users. How is this ``why''? |That is critical for IPv6 to solve right now. Margaret's |proposal solves that problem and will save lives IMO with IPv6. Save lives? Aren't you exaggerating a bit? It may save jobs at ISPs since they will have more revenue from charging for all the addresses that could have been site-locals... and more control from making it harder to switch providers... but only until v6 NAT takes off... |But TCP because we have sites and not multiple links connected using |global addresses I don't believe provides any more guarantee or |robustness for a long lived TCP connection on a site. Simply because |the only reason it will break the site TCP is an error in the network |administration, router going down (then we get into dual rail but lets |not go there for now), or the cosmos sends a lighting bolt into the core |router of the site. So SLs buy a site TCP long lived connections |nothing I can see over global addresses. The only place that is not |true is a link. And for that we do have link-local. So I still do not |see the value of SLs even for long lived connections. I'm afraid you are missing the point. The internal structure of a site network is under the control of that site. The administration can make the network as reliable as their needs require, even provisioning completely redundant cores to survive that lightning bolt. Contrary to what some people seem to believe, some entities use their networks for more than just making connections to the outside world from web browser clients. The stability of their internal network is important to their business or even to their (or our) safety. Margaret's proposal forces such sites to depend on the stability of their ISP just because they want global connectivity. Such an absurdity will not stand in the market. Under these rules we *will* have v6 NAT in no time. |The way to solve long lived connections and this is even more hairy than |SLs and that is by dynamically reconfiguring the two nodes to use |different addresses and vendor customized True High Availability for TCP |and SCTP (I believe SCTP is better now just like IPv6 is better than |IPv4 but needs more testing and trial networks). There is always a different/better solution just around the corner. Soon we will have transparent renumbering and recoverable tcp. I've been hearing this for years. It's a fantasy. There are many deep dependencies on stable identifiers at all levels. Networks are going to need stable addresses for the foreseeable future. ISPs may believe that they can extract arbitrary fees for providing those stable addresses, but it isn't going to happen. |So I am not clear your argument of long lived connections is an argument |for SLs? That isn't my argument. My argument would be for portable routable addresses or identifiers, but I lost. The arguments for site-local addressing were made years ago. It isn't clear why they have all been forgotten. |It is an argument for other work I believe to be important. Sure, implement my portable identifier protocol and all the problems will go away. Or allow portable routable addresses. The hardware has gotten a lot faster and memory has gotten a lot cheaper. Or solve the renumbering and address allocation problems without the former. But whatever you do, do it FIRST and then come back so we can discuss removing the last vestige of supported end-user-controlled address space. Keith Moore wrote: |first, I don't buy that provider-based addresses are inherently that much |of a burden. They seem to be enough of a burden to cause NAT to flourish, though. |and it's far easier to solve the renumbering problem (particularly |for special-purpose devices) than to solve the SL addressibility problem. So we are coming full circle? We have the renumbering problem because the portable address/identifier problem was declared by fiat to be too hard to even think about solving. We are stuck with site-local addressing because the renumbering problem turned out to be too difficult to solve in practice. I've noticed an unfortunate trend towards the following kind of argument: ``X is bad, unaesthetic, and hard. I don't like x. The world will be much better if we eliminate x now and replace its functionality with y at some point in the future. Y is easier, cleaner, and more aesthetic. As soon as someone manages to implement y everybody will see this. I don't have an implementation of y right now, of course. But it will happen.'' Site-locals are already at least a third-order compromise. You aren't even proposing a new "y"... If you think that the renumbering problem is easy solve, can I make a suggestion similar to the ones I received when I proposed portable identifiers? Go make it work. Bring back a few sample implementations that demonstrate transparent renumbering. Write it up. Get the necessary changes made in whatever standards are affected. With renumbering solved I think you will see less resistance to elimination of site-locals, though there is still the address cost issue. Now in my opinion, renumbering is a very hard problem to solve--much harder than either portable identifiers or scope propagation. (At least, renumbering is hard to solve if you don't introduce a level of indirection that is equivalent to portable identifiers.) But I'd be happy to be proven wrong. |second, I don't buy that we're stuck with provider-based addresses anyway. Can you expand on this? If you know a way to get unstuck from provider-based addresses I'd love to hear about it. With a mechanism for end users to own portable routable global addresses the need for site-locals would be greatly reduced. But if you are just talking about a hypothetical future utopia then it is unreasonable to use this as a reason to deprecate site-locals. The ipv4 address aggregation hack was supposed to be a temporary stopgap until the hardware caught up. The hardware caught up a long time ago. You still can't get portable v4 address space in any reasonable way. I see no reason to believe that v6 addresses will fair any better. If you are talking about non-routable global addresses then this is a step in the right direction, but it isn't clear that it removes the need to deal with scopes and DNS hacks. If you are talking about 6to4 space then you have found an illusory solution. |third, I don't buy that every company wants to set up its own infrastructure |to network to remote devices when they can take bids from competing providers |who already have infrastructure - or even use a mixture of providers. |(for instance, you can combine wired, wireless, satellite depending on |where your devices are) Do you buy that most companies want to set up their own infrastructure to network to *local* devices without depending on their ISP? Should access to my local network printer really depend on an address assignment from my ISP? Even for remote devices accessed via third-party infrastructure the increased use of VPNs may well mean that those remote devices will have addresses local to the the owner. |fourth, I don't buy that the existence of provider-based addresses is a |compelling reason to burden us with SLs. See #1. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:19:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMJn29015867; Wed, 30 Oct 2002 14:19:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMJnEu015866; Wed, 30 Oct 2002 14:19:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMJk29015859 for ; Wed, 30 Oct 2002 14:19:46 -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 g9UMJsbB027369 for ; Wed, 30 Oct 2002 14:19:54 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04600 for ; Wed, 30 Oct 2002 15:19:48 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA25624; Wed, 30 Oct 2002 14:19:29 -0800 (PST) Message-Id: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 17:20:53 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Keith Moore" , 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 don't understand this. In your proposal, every site will be filtering >a different global prefix. Routers in the internet backbone will not be >filtering any global prefix. Where is the comparable defense in the >depth? I think it depends what you mean by "filtering a prefix"... If you use a global prefix to number a private site, you wouldn't necessarily advertise that prefix in global routing tables. In fact, it would be best not to. So, it wouldn't be any more "routable" on the Internet than a site-local prefix. Routers wouldn't have any path to it, so they'd drop it... Also, I am under the impression that ISPs do some filtering at the customer bounday -- only allowing traffic from a customers' global prefix(es) out, and only letting traffic to the customers' global prefix(es) in... How common is this? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:21:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UML229015896; Wed, 30 Oct 2002 14:21:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UML2w6015895; Wed, 30 Oct 2002 14:21:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMKx29015888 for ; Wed, 30 Oct 2002 14:20:59 -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 g9UML6Mq022932 for ; Wed, 30 Oct 2002 14:21:06 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29845 for ; Wed, 30 Oct 2002 14:21:00 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9UMKsBM066922 for ; Thu, 31 Oct 2002 09:20:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210302220.g9UMKsBM066922@drugs.dv.isc.org> To: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 16:53:35 CDT." <5.1.0.14.2.20021030164823.00a95080@mail.windriver.com> Date: Thu, 31 Oct 2002 09:20:54 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Some of these complexities don't apply to link-local addresses, because > no one expects to put them in the DNS, This is tunnel vision. The only reason that no one expects them in the DNS is that we havn't added support for them in the DNS. I think LL (and SL) should be in the DNS. Doing this actually simplifies things. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:24:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMO829015960; Wed, 30 Oct 2002 14:24:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMO7Z9015959; Wed, 30 Oct 2002 14:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMO329015949 for ; Wed, 30 Oct 2002 14:24:03 -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 g9UMOBbB028698 for ; Wed, 30 Oct 2002 14:24:11 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00522 for ; Wed, 30 Oct 2002 15:24:05 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UMNu006214; Wed, 30 Oct 2002 17:23:56 -0500 (EST) Message-Id: <200210302223.g9UMNu006214@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 14:02:28 PST.") Date: Wed, 30 Oct 2002 17:23:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > when a site renumbers the routers are going to have to be updated > > anyway. of course we need a solution for this problem. but > > having site locals won't change the need to reconfigure > > routers when renumbering. > > You haven't contested my point that the security based on site-locals > will not be comprised when a site renumbers, whereas security based on > the filtering of a global prefix is vulnerable to mishap during > renumbering. So I take it you agree that site-locals do offer an > advantage here? no, I really don't think so. the notion of a "site" being a useful security boundary is mostly an illusion anyway - it's far too coarse-grained. and if people actually try to use this in nontrivial networks it seems likely that they'll continually have to be juggling router configuration to manage connectivity between different portions (potential "site" boundaries) within their enterprise network. > > the same kind of defense in depth is possible (and quite reasonable) > > with prefix filtering - and it's more flexible since it > > doesn't require the same prefix length to be filtered at each router. > > I don't understand this. In your proposal, every site will be filtering > a different global prefix. Routers in the internet backbone will not be > filtering any global prefix. Where is the comparable defense in the > depth? the defense in depth is within the enterprise. every router within the site will admit traffic only from/to those prefixes that make sense for that particular part of the network. if the traffic passes through multiple routers then each router is a separate barrier. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:27:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMRm29016162; Wed, 30 Oct 2002 14:27:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMRmbM016161; Wed, 30 Oct 2002 14:27:48 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMRj29016154 for ; Wed, 30 Oct 2002 14:27:45 -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 g9UMRrMq024950 for ; Wed, 30 Oct 2002 14:27:53 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09962 for ; Wed, 30 Oct 2002 15:27:47 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 14:27:50 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: Default site-local behavior for routers Date: Wed, 30 Oct 2002 14:27:26 -0800 Message-ID: <082601c28063$88763100$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20021030162312.01a67130@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UMRj29016155 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > I've had an action item for a while to summarize the thread > that led to this conclusion to the IPv6 list, but I haven't > gotten to it yet. I'll do so soon. I appreciate that work loads make a summary effort challenging, but in this particular case it would seem the lower effort path would be to cut off the IPv6 thread by forwarding the analysis. Hopefully it will make it clear to all that the scope of SL can't exceed the scope of the IGP, and shouldn't exceed the configured sub-scopes of that IGP without explicit configuration. 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 Wed Oct 30 14:31:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMVf29016298; Wed, 30 Oct 2002 14:31:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMVfXA016297; Wed, 30 Oct 2002 14:31:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMVc29016287 for ; Wed, 30 Oct 2002 14:31: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 g9UMVkbB001105 for ; Wed, 30 Oct 2002 14:31:46 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11163 for ; Wed, 30 Oct 2002 14:31:40 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA25015; Wed, 30 Oct 2002 22:31:34 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <5.1.0.14.2.20021030161904.07aefb30@mail.windriver.com> From: Ole Troan Date: Wed, 30 Oct 2002 22:31:34 +0000 In-Reply-To: <5.1.0.14.2.20021030161904.07aefb30@mail.windriver.com> (Margaret Wasserman's message of "Wed, 30 Oct 2002 16:22:21 -0500") Message-ID: <7t51y67zhh5.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >>I didn't say anything about site-locals and security >>and I didn't ask what link-locals are for. I said >>that you can create a tunnel to take link-locals >>beyond a link, so the problem is not specific to >>site-locals. > > Actually, I think that there are some important differences > between link-locals and site-locals. > > A router might (and probably should) be hard-coded not to > forward link-local packets, as there is no reason to ever > forward them. one might imagine links where hosts need to use the router to reach other hosts, e.g radio links, NBMA networks. more importantly what purpose does it solve? routers will only forward traffic to link-local destinations out the same link. > However, a router that might ever need have multiple interfaces > in a single site can't be hard-coded not to forward site-locals. > Whether or not they will be forwarded is the result of > configuration. > > There is another important difference that doesn't relate > directly to security (as far as I know): site-local prefixes > are advertised by routers, and they differ from link to link > (different subnet IDs), whereas the link-local prefix is a > single constant. with regards filtering traffic to site-local destinations. one would not use normal traffic filters for this, as the incoming interface decides which site the packet belongs to, and thereby which forwarding table to do the lookup in. making the border interface belong to a different site than any other interface achieves this. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:56:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMu129016709; Wed, 30 Oct 2002 14:56:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMu1D4016708; Wed, 30 Oct 2002 14:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMts29016698 for ; Wed, 30 Oct 2002 14:55: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 g9UMu2bB007922 for ; Wed, 30 Oct 2002 14:56:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28412 for ; Wed, 30 Oct 2002 15:55:57 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UMsd006434; Wed, 30 Oct 2002 17:54:40 -0500 (EST) Message-Id: <200210302254.g9UMsd006434@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 09:20:54 +1100.") <200210302220.g9UMKsBM066922@drugs.dv.isc.org> Date: Wed, 30 Oct 2002 17:54:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is tunnel vision. The only reason that no one expects them in the DNS is that we havn't added support for them in the DNS. well, that and the minor consideration that current DNS architecture assumes that names are global and that queries return consistent results everywhere. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:55:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMtw29016706; Wed, 30 Oct 2002 14:55:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMtwn7016705; Wed, 30 Oct 2002 14:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMtr29016691 for ; Wed, 30 Oct 2002 14:55:53 -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 g9UMu1bB007916 for ; Wed, 30 Oct 2002 14:56:01 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24935 for ; Wed, 30 Oct 2002 15:55:52 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 670003B371; Thu, 31 Oct 2002 09:55:49 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: Margaret Wasserman Cc: Richard Draves , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> References: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 09:55:49 +1100 Message-Id: <1036018549.7840.321.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-10-31 at 09:20, Margaret Wasserman wrote: > > > > >I don't understand this. In your proposal, every site will be filtering > >a different global prefix. Routers in the internet backbone will not be > >filtering any global prefix. Where is the comparable defense in the > >depth? > > I think it depends what you mean by "filtering a prefix"... > > If you use a global prefix to number a private site, you wouldn't > necessarily advertise that prefix in global routing tables. In > fact, it would be best not to. So, it wouldn't be any more > "routable" on the Internet than a site-local prefix. Routers > wouldn't have any path to it, so they'd drop it... > > Also, I am under the impression that ISPs do some filtering at the > customer bounday -- only allowing traffic from a customers' global > prefix(es) out, and only letting traffic to the customers' global > prefix(es) in... How common is this? > Quite common. I think the motivation for doing this is to prevent traffic holding any private addressing or unauthorised public addressing from leaking from the site. On a related topic, if I was to stuff up my site local filters at the edge of my site, would my network then become part of my ISPs site local network ? In the proposed site-local models, are sites adjacent, or are they separated by segments that only have a global address assignments (eg the BGP AS model vs the OSPF area model) ? Regards, Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:57:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMvW29016735; Wed, 30 Oct 2002 14:57:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMvWnk016734; Wed, 30 Oct 2002 14:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMvR29016727 for ; Wed, 30 Oct 2002 14:57:27 -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 g9UMvZbB008337 for ; Wed, 30 Oct 2002 14:57:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29221 for ; Wed, 30 Oct 2002 15:57:29 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UMvG006455; Wed, 30 Oct 2002 17:57:16 -0500 (EST) Message-Id: <200210302257.g9UMvG006455@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 13:58:55 PST.") <2B81403386729140A3A899A8B39B04640BD286@server2000> Date: Wed, 30 Oct 2002 17:57:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Why should I believe that a sufficiently determined > > adversary couldn't somehow obtain a bootleg copy of > > IOS source? > > So tell me which of the following setups is the most secure: > > a) The one that requires, in order to be hacked, to get a bootleg copy > of the IOS source, all the tools needed to compile it, understand how it > works, be able to modify the code... > > b) The one that does not? you don't have to have the source to IOS in order to figure out a way to get a router to tunnel the traffic to a compromised, programmable host of your choosing. just build the attack into a mail virus. then all you need is one client inside the firewall running outlook express... Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 14:57:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMvq29016748; Wed, 30 Oct 2002 14:57:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UMvpqx016747; Wed, 30 Oct 2002 14:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UMvk29016740 for ; Wed, 30 Oct 2002 14:57:47 -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 g9UMvsMq004363 for ; Wed, 30 Oct 2002 14:57:54 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26013 for ; Wed, 30 Oct 2002 15:57:48 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 14:57:53 -0800 Reply-To: From: "Tony Hain" To: "'Dan Lanciani'" , Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 14:57:29 -0800 Message-ID: <082701c28067$b9985430$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210302215.RAA16413@ss10.danlan.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UMvl29016741 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > ... > The thing that bothers me about this discussion is that it is > starting to sound as if site-local addressing (and all the > endless debate about scope and address selection rules) was > just another sham like transparent renumbering. Until a few > days ago site-local addresses (along with the scope baggage they > entail) were a part of the IPv6 vision. Now suddenly they > are a minor wart to be eliminated, and all roads seem to lead > back to the situation where the stability (and cost) of your > internal network is directly dependent on your ISP. This in > turn will almost certainly result in the introduction of IPv6 > NAT and we will be right back where we started. Please don't interpret the ranting of a few as representing anything close to consensus of a very large WG. Your comments are very valuable as they keep the real end use requirements in focus, and push the 'its too hard' wining to the background. I do have one question about your comment, do you believe transparent renumbering is a sham, or did I mis-read your intent? > > > Margaret Wasserman wrote: > > |Seriously, we have an opportunity, with the introduction of IPv6, to > |advocate new ways of doing things on the new network. > | > |Just because people have been doing something one (bad) way > |in the past, doesn't mean that we should advocate that approach in > |IPv6. > > Wow. I think I used almost exactly those words a few years > back in a futile argument for global portable identifiers. > But you seem to be advocating constraining v6's addressing to > work just as v4's does. How is that new? > > One of the (IMHO, very few) benefits of the v6 addressing > architecture is that scoped site-local addresses allow some > of the desirable functionality of NAT and private addressing > to integrate smoothly. I'm not saying that this was a good > tradeoff. I would have preferred to see work on the routing > problem so that everybody could have their own stable > routable addresses. But that would have upset the status quo > a bit too much and we got scopes instead. The bottom line is > that by hand-waving arguments scoped addressing was declared > feasible while routing portable addresses was declared > impossible. The bed has been made and now we have to lie in it... There is an ongoing discussion on multi6 about how we might get a compromise version of stable global & routable identifiers, but it is not converging anytime soon. > > > "Bound, Jim" wrote: > > |Dan, > | ... > > |So I am not clear your argument of long lived connections is an > |argument for SLs? > > That isn't my argument. My argument would be for portable > routable addresses or identifiers, but I lost. The arguments > for site-local addressing were made years ago. It isn't > clear why they have all been forgotten. Because those who made them thought it was essentially finished and moved on to real problems, while those who lost figure the lack of attention represents a good opportunity to revisit the discussion and win this time. > > |It is an argument for other work I believe to be important. > > Sure, implement my portable identifier protocol and all the > problems will go away. Or allow portable routable addresses. > The hardware has gotten a lot faster and memory has gotten a > lot cheaper. Or solve the renumbering and address allocation > problems without the former. But whatever you do, do it > FIRST and then come back so we can discuss removing the last > vestige of supported end-user-controlled address space. Your point is there will be end-user-controlled address space, the only option we have now is SL but we only need one mechanism that meets the requirement. > > > Keith Moore wrote: > > |first, I don't buy that provider-based addresses are inherently that > |much > |of a burden. > > They seem to be enough of a burden to cause NAT to flourish, though. > > |and it's far easier to solve the renumbering problem > (particularly for > |special-purpose devices) than to solve the SL addressibility problem. > > So we are coming full circle? We have the renumbering > problem because the portable address/identifier problem was > declared by fiat to be too hard to even think about solving. > We are stuck with site-local addressing because the > renumbering problem turned out to be too difficult to solve > in practice. Please explain... I understand that renumbering and static configuration of things like filters can be a challenge, but those are solvable given a reasonable time period. Is this simply a matter of an app can't survive a reunmbering event? > > I've noticed an unfortunate trend towards the following kind > of argument: ``X is bad, unaesthetic, and hard. I don't > like x. The world will be much better if we eliminate x now > and replace its functionality with y at some point in the > future. Y is easier, cleaner, and more aesthetic. As soon > as someone manages to implement y everybody will see this. I > don't have an implementation of y right now, of course. But > it will happen.'' Site-locals are already at least a > third-order compromise. You aren't even proposing a new "y"... This is because there is a complete lack of appreciation for the fundemental requirement that a network manager have stable locally controlled address space. > > If you think that the renumbering problem is easy solve, can > I make a suggestion similar to the ones I received when I > proposed portable identifiers? Go make it work. Bring back > a few sample implementations that demonstrate transparent > renumbering. Write it up. Get the necessary changes made in > whatever standards are affected. With renumbering solved I > think you will see less resistance to elimination of > site-locals, though there is still the address cost issue. > Now in my opinion, renumbering is a very hard problem to > solve--much harder than either portable identifiers or scope > propagation. (At least, renumbering is hard to solve if you > don't introduce a level of indirection that is equivalent to > portable identifiers.) But I'd be happy to be proven wrong. As a slightly off topic question, do you agree with the business driver assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about the approach in the PI format, but the fundamental reasons should be consistent. > > |second, I don't buy that we're stuck with provider-based addresses > |anyway. > > Can you expand on this? If you know a way to get unstuck > from provider-based addresses I'd love to hear about it. > With a mechanism for end users to own portable routable > global addresses the need for site-locals would be greatly > reduced. But if you are just talking about a hypothetical > future utopia then it is unreasonable to use this as a reason > to deprecate site-locals. The ipv4 address aggregation hack > was supposed to be a temporary stopgap until the hardware > caught up. The hardware caught up a long time ago. You > still can't get portable v4 address space in any reasonable > way. I see no reason to believe that v6 addresses will fair > any better. > > If you are talking about non-routable global addresses then > this is a step in the right direction, but it isn't clear > that it removes the need to deal with scopes and DNS hacks. Non-routable global addresses are by definition local. The only thing they bring to the table over SL is ambiguity in the scope of routability. Keith continues to argue that he wants to remove ambiguity, but what he is really arguing is that it be moved outside the visibility of his multi-party app development window. Tony > > If you are talking about 6to4 space then you have found an > illusory solution. > > |third, I don't buy that every company wants to set up its own > |infrastructure to network to remote devices when they can > take bids from competing providers > |who already have infrastructure - or even use a mixture of > providers. > |(for instance, you can combine wired, wireless, satellite > depending on > |where your devices are) > > Do you buy that most companies want to set up their own > infrastructure to network to *local* devices without > depending on their ISP? Should access to my local network > printer really depend on an address assignment from my ISP? > Even for remote devices accessed via third-party > infrastructure the increased use of VPNs may well mean that > those remote devices will have addresses local to the the owner. > > |fourth, I don't buy that the existence of provider-based > addresses is a > |compelling reason to burden us with SLs. > > See #1. > > Dan Lanciani > ddl@danlan.*com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:02:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN2s29016881; Wed, 30 Oct 2002 15:02:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN2sUD016880; Wed, 30 Oct 2002 15:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN2o29016868 for ; Wed, 30 Oct 2002 15:02:50 -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 g9UN2wbB010041 for ; Wed, 30 Oct 2002 15:02:58 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02712 for ; Wed, 30 Oct 2002 16:02:52 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 15:02:51 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3DC@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAZ836kHzk6ju7STeHv3Fo328REgAABrKQ From: "Michel Py" To: "Keith Moore" Cc: , "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UN2o29016870 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > you don't have to have the source to IOS in order to > figure out a way to get a router to tunnel the traffic > to a compromised, programmable host of your choosing. > just build the attack into a mail virus. then all you > need is one client inside the firewall running outlook > express... You're running out of gas, pal. Control devices on a utility network do not have Outlook Express. 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 Oct 30 15:05:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN5Y29016956; Wed, 30 Oct 2002 15:05:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN5XbF016955; Wed, 30 Oct 2002 15:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN5U29016948 for ; Wed, 30 Oct 2002 15:05:30 -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 g9UN5cbB010807 for ; Wed, 30 Oct 2002 15:05:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00483 for ; Wed, 30 Oct 2002 16:05:32 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 15:05:37 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 15:05:14 -0800 Message-ID: <082801c28068$ce6a6af0$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UN5U29016949 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > I think it depends what you mean by "filtering a prefix"... > > If you use a global prefix to number a private site, you > wouldn't necessarily advertise that prefix in global routing > tables. Yes you would, because that private site is most likely part of a larger enterprise, so the parts that get advertised will be a /48 or shorter, while the parts that want to stay disconnected would be a /56 or longer. > In fact, it would be best not to. So, it wouldn't > be any more "routable" on the Internet than a site-local > prefix. Routers wouldn't have any path to it, so they'd drop it... This is only true if the site trying to stay out of the table was represented by a /48 or shorter. If not, the ISP filter will simply drop the longer advertisements and the part of the enterprise that didn't want to be globally accessable would suddenly find that they were reachable. > > Also, I am under the impression that ISPs do some filtering > at the customer bounday -- only allowing traffic from a > customers' global > prefix(es) out, and only letting traffic to the customers' global > prefix(es) in... How common is this? Not as common as it needs to be (see nanog discussion today on this topic), but even if it did happen everywhere, it does not mean that parts of a /48 can be globally routed while other parts are not. Tony > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:05:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN5u29016975; Wed, 30 Oct 2002 15:05:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN5u1a016974; Wed, 30 Oct 2002 15:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN5o29016964 for ; Wed, 30 Oct 2002 15:05:50 -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 g9UN5wbB010919 for ; Wed, 30 Oct 2002 15:05:58 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01670 for ; Wed, 30 Oct 2002 15:05:52 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 623FF18E3 for ; Wed, 30 Oct 2002 18:05:48 -0500 (EST) Date: Wed, 30 Oct 2002 18:05:48 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021030163315.07b24ec0@mail.windriver.com> References: <4DA6EA82906FD511BE2F00508BCF0538044F0C49@Esealnt861.al.sw.ericsson.se> <5.1.0.14.2.20021030163315.07b24ec0@mail.windriver.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021030230548.623FF18E3@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've heard this argument that site-local addresses somehow make the site border router filtering problem easier, and I don't get it. As far as I can tell, they don't help at all, and in fact just make the problem a little worse. I have to filter all the kinds of addresess that shouldn't be crossing my router anyway (eg, ingress filtering, various whacky combinations of transition address spaces with various kinds of IPv4 addresses, etc), whether applications in my site are using site-local addresses or not. Site-local addresses are just one more flipping thing I have to filter. So how were site-local addresess helping me with this problem again? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:06:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN6R29017001; Wed, 30 Oct 2002 15:06:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN6RUB017000; Wed, 30 Oct 2002 15:06:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN6J29016993 for ; Wed, 30 Oct 2002 15:06:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UN6RbB011070 for ; Wed, 30 Oct 2002 15:06:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02062; Wed, 30 Oct 2002 15:06:21 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UN6B006618; Wed, 30 Oct 2002 18:06:11 -0500 (EST) Message-Id: <200210302306.g9UN6B006618@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , sommerfeld@east.sun.com, "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 15:02:51 PST.") <2B81403386729140A3A899A8B39B046405E3DC@server2000> Date: Wed, 30 Oct 2002 18:06:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > you don't have to have the source to IOS in order to > > figure out a way to get a router to tunnel the traffic > > to a compromised, programmable host of your choosing. > > just build the attack into a mail virus. then all you > > need is one client inside the firewall running outlook > > express... > > You're running out of gas, pal. Control devices on a utility network do > not have Outlook Express. if you think that the only place that SLs will be used on a utility network, or that people can be relied to put all devices that need protecting on a separate network, you're living under a rock. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:07:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN7l29017054; Wed, 30 Oct 2002 15:07:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN7lix017053; Wed, 30 Oct 2002 15:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN7h29017040 for ; Wed, 30 Oct 2002 15:07:44 -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 g9UN7pMq007813 for ; Wed, 30 Oct 2002 15:07:51 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02814 for ; Wed, 30 Oct 2002 15:07:46 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA26451; Wed, 30 Oct 2002 23:07:43 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Brian Haberman Cc: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <3DC028E1.4060605@nc.rr.com> From: Ole Troan Date: Wed, 30 Oct 2002 23:07:43 +0000 In-Reply-To: <3DC028E1.4060605@nc.rr.com> (Brian Haberman's message of "Wed, 30 Oct 2002 13:45:53 -0500") Message-ID: <7t5y98fy18g.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, one of the items that Margaret suggested was some text in > the node requirements doc or the scoped addr arch that states > that nodes default to being in one site. > > However, there has been some mention that people would prefer > different behavior in routers. That is, the stated desire > was that, by default, each interface on a router be in its own > site. > > This suggestion leads to the model where hosts with multiple > interfaces will assume that all its interfaces are in the > same site (e.g. have the same site-local zone id) unless > explicitly configured to have multiple sites. While routers > will default to having a unique site-local zone id for each > interface (thus rendering SLs to link-local behavior) unless > explicitly configured to have multiple interfaces in the > same site. > > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. > > What are others' opinions on this issue? I think default behaviour should be that a router treats site-locals just as global addresses, i.e all interfaces in the same site. - site borders need to be configured. - a router connected to multiple sites needs to be configured. we should not require all router implementations to support "multi-site" behaviour. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:09:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN9u29017137; Wed, 30 Oct 2002 15:09:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UN9u4q017136; Wed, 30 Oct 2002 15:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UN9r29017129 for ; Wed, 30 Oct 2002 15:09:53 -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 g9UNA1bB012141 for ; Wed, 30 Oct 2002 15:10:01 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02406 for ; Wed, 30 Oct 2002 16:09:55 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 15:10:00 -0800 Reply-To: From: "Tony Hain" To: "'Mark Smith'" , "'Margaret Wasserman'" Cc: "'Richard Draves'" , "'Keith Moore'" , Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 15:09:37 -0800 Message-ID: <082901c28069$6b1a6ad0$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1036018549.7840.321.camel@dupy> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UN9r29017130 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark Smith wrote: > ... > On a related topic, if I was to stuff up my site local > filters at the edge of my site, would my network then become > part of my ISPs site local network ? You would both have to make an error to get the two IGPs tied together. > In the proposed > site-local models, are sites adjacent, or are they separated > by segments that only have a global address assignments (eg > the BGP AS model vs the OSPF area model) ? I remember this discussion a few months back, but I don't remember the conclusion. Maybe Ole does. 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 Wed Oct 30 15:14:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNEB29017302; Wed, 30 Oct 2002 15:14:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNEBtX017301; Wed, 30 Oct 2002 15:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNE729017294 for ; Wed, 30 Oct 2002 15:14:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9UNEFbB013438 for ; Wed, 30 Oct 2002 15:14:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29399 for ; Wed, 30 Oct 2002 16:14:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9UNE4006762; Wed, 30 Oct 2002 18:14:04 -0500 (EST) Message-Id: <200210302314.g9UNE4006762@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Dan Lanciani'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 14:57:29 PST.") <082701c28067$b9985430$4b194104@eagleswings> Date: Wed, 30 Oct 2002 18:14:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please don't interpret the ranting of a few as representing anything > close to consensus of a very large WG. yes, please don't. it's very clear that we don't have consensus to use SLs except on an isolated network. attempts by a few individuals to legitimize SLs in the face of considerable complexity and marginal benefit, without technical justification, should be ignored. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:15:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNFj29017391; Wed, 30 Oct 2002 15:15:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNFjPv017390; Wed, 30 Oct 2002 15:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNFf29017383 for ; Wed, 30 Oct 2002 15:15: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 g9UNFnMq010342 for ; Wed, 30 Oct 2002 15:15:50 -0800 (PST) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00218 for ; Wed, 30 Oct 2002 16:15:43 -0700 (MST) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 2ECD7146D8; Thu, 31 Oct 2002 10:15:28 +1100 (EST) Date: Thu, 31 Oct 2002 10:15:27 +1100 From: "Nick 'Sharkey' Moore" To: "Hesham Soliman (EAB)" Cc: "'James Kempf'" , "Bound, Jim" , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Changing RS Reply Timing for Mobile IPv6 Message-ID: <20021031101525.B18189@dwerryhouse.com.au> References: <4DA6EA82906FD511BE2F00508BCF0538044F0C1C@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C1C@Esealnt861.al.sw.ericsson.se>; from hesham.soliman@era.ericsson.se on Tue, Oct 29, 2002 at 07:08:55PM +0100 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Oct 29, 2002 at 07:08:55PM +0100, Hesham Soliman (EAB) wrote: > > Optimistic DAD needs to be analysed carefully to make sure > that the failure cases are rare and do not justify killing > optimistic DAD. I think this analysus is ongoing. Yep. it's ongoing! No-one seems to have come up with a killer (eg: something which doesn't fix itself with NUD) yet, but the more eyes the merrier. I'm working on version -01 which will fix some editorial points and change some SHOULDs into MAYs and so on to better reflect the feedback I've been getting ... and there's a Linux implementation on the way for test purposes. I'm not sure Optimistic DAD is the solution, or even part of the solution ... it's more an attempt to make some forward progress on the fast, smooth handovers front. If it provides useful points of comparison for the 'official' FMIP effort, it's done its job. -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:16:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNGp29017454; Wed, 30 Oct 2002 15:16:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNGp7V017453; Wed, 30 Oct 2002 15:16:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNGk29017440 for ; Wed, 30 Oct 2002 15:16:46 -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 g9UNGsbB014294 for ; Wed, 30 Oct 2002 15:16:54 -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 QAA10776 for ; Wed, 30 Oct 2002 16:16:48 -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 91C6276B2; Wed, 30 Oct 2002 18:16:47 -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, 30 Oct 2002 18:16:43 -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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 18:16:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B641@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAV9Hhi7JK/WnVQD+iLXQF+FbwagAEbLgQ From: "Bound, Jim" To: , "Tim Hartrick" , , X-OriginalArrivalTime: 30 Oct 2002 23:16:43.0563 (UTC) FILETIME=[68F5E7B0:01C2806A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UNGl29017441 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony and Tim, I agree with Tim about the flow. But I strongly support Margarets idea to limit them today to not be part of domain where global addresses exist as Margaret has clearly articulated. Support for that is not a minority and not rehash but putting some controls on an architectural part of IPv6 that is not understood, widely implemented, or deployed as product with express warranty that it can be used in production networks. So keep it in the architecture and lets put a control on it right now and move on. I am personally not going to participate any further I have nothing else to say. P.S. Tim I emphatically do not agree with your views on 1918 and I was here as you when it was developed. But I see no point in kicking that dead horse either. We simply do not agree. It is moot point though I do agree. P.S. Margaret if we can get folks to do this correct engineering change order I will help with the draft if you require that. But for now I am DELETING all this mail on killing SLs entirely it will not happen. Though they should die and all should use globals the next best thing is to put controls on this mess until we understand how to do it. /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, October 30, 2002 4:01 PM > To: 'Tim Hartrick'; ipng@sunroof.eng.sun.com; richdr@microsoft.com > Subject: RE: Limiting the Use of Site-Local > > > Thank you! > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tim Hartrick > > Sent: Tuesday, October 29, 2002 4:41 PM > > To: ipng@sunroof.eng.sun.com; richdr@microsoft.com > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > > All, > > > > I generally agree with all the points that Richard Draves has > > made. I am not as sanguine about the ease of implementation > > in the network stack but there is nothing in the details > > which is unimaginably difficult. We very much need to move > > on. By my count this is the forth or fifth time this topic > > has been debated and redebated. Each time the result has > > been the same. If every decision taken by this working group > > can be opened repeatedly by a noisy minority then forward > > progress of any sort will not be possible. Consensus does > > not require unanimity. No matter how noisy and persistent > > the minority happens to be, it is possible to move on. > > > > There are a couple of other points I would like to make. > > > > Some folks seem to be operating under a misconception about > > RFC 1918. RFC 1918 was a response to the rampant use of > > arbitrary IPv4 prefixes as private address space. The use of > > private address space was not a response to the publishing of > > RFC 1918. Network administrators will use "private" IPv6 > > address space whether we excise all mention of site-local > > addresses from the specifications or not. The network > > administrators that use private address space may be stupid, > > misinformed or have any number of socially unacceptable > > habits but they still run their networks and will run their > > networks the way they see fit. Removing site-local addresses > > from the architecture or attempting to restrict their use in > > a way that is equivalent to removing them is an exercise in > > futility absent better alternatives to site-local addresses. > > > > The burden on those that want to remove site-local addresses > > is to provide network administrators with an alternative > > which meets their needs but doesn't possess the negative > > aspects of site-local addresses that are being railed > > against. The requirements that network adminstrators would > > place on these addresses would probably be that there is no > > registration required and that the addresses are not globally > > routable. If such a proposal has been made and it has made > > it through last call of this working group, I must have > > missed it. Contrary to what has been said by some in the > > anti-site-local camp, the burden should be on them to come up > > with alternatives to site-local addresses. Until those > > alternatives have been thoroughly vetted by this working > > group the previous consensus should hold. > > > > Counter to what one might believe from reading my comments > > above, I don't like the architectural mess that has occured > > as a consequence of the use private addresses in IPv4. The > > difference between me and the anti-site- local camp is that I > > don't anticipate that network administrators will stop using > > private address (IPv6 or IPv4) unless they are provided with > > good reasons not to use them. That means solving > > renumbering, solving address shortage, artificial or > > otherwise, providing the an alternative "private" address > > scheme of the sort cited above and providing the great IPv6 > > applications which their customers want but that break in the > > presence of site-local addresses. If these things are done, > > it won't be necessary to add a bunch of MUST NOTs into the > > verbiage in various specifications. Site-local addresses and > > all the associated problems will fall into the dustbin of > > obsolescence. Absent these things, all the MUST NOTs in the > > world won't prevent the use of site-local addresses or some > > other form of IPv6 "private" address. > > > > Network administrators don't read RFCs for the MUST NOTs. > > They read them for the solutions they provide. If the MUST > > NOTs get in the way of the solution then they get ignored. > > > > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 30 15:23:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNNF29017642; Wed, 30 Oct 2002 15:23:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNNFC5017641; Wed, 30 Oct 2002 15:23:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNNC29017631 for ; Wed, 30 Oct 2002 15:23: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 g9UNNKbB016365 for ; Wed, 30 Oct 2002 15:23:20 -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 PAA05696 for ; Wed, 30 Oct 2002 15:23:14 -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 0C8CB767A; Wed, 30 Oct 2002 18:23:14 -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, 30 Oct 2002 18:23: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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 18:23:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97C1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAV9Hhi7JK/WnVQD+iLXQF+FbwagAEbLgQAABjJ3A= From: "Bound, Jim" To: "Bound, Jim" , , "Tim Hartrick" , , X-OriginalArrivalTime: 30 Oct 2002 23:23:09.0985 (UTC) FILETIME=[4F493910:01C2806B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UNNC29017632 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would also ask all those who want to kill SLs turn your support to Margaret to put the controls on. My input to you is you cannot win this battle. But if we support Margarets idea with consenus then at least for now we can control them. And I don't like the idea for IPv6 deployment reasons messing with the architecture spec at all. Think about it. Compromise is part of timely engineering whether we like it or not. /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Bound, Jim > Sent: Wednesday, October 30, 2002 6:17 PM > To: alh-ietf@tndh.net; Tim Hartrick; > ipng@sunroof.eng.sun.com; richdr@microsoft.com > Subject: RE: Limiting the Use of Site-Local > > > Tony and Tim, > > I agree with Tim about the flow. But I strongly support > Margarets idea to limit them today to not be part of domain > where global addresses exist as Margaret has clearly > articulated. Support for that is not a minority and not > rehash but putting some controls on an architectural part of > IPv6 that is not understood, widely implemented, or deployed > as product with express warranty that it can be used in > production networks. > > So keep it in the architecture and lets put a control on it > right now and move on. > > I am personally not going to participate any further I have > nothing else to say. > > P.S. Tim I emphatically do not agree with your views on 1918 > and I was here as you when it was developed. But I see no > point in kicking that > dead horse either. We simply do not agree. It is moot > point though I > do agree. > > P.S. Margaret if we can get folks to do this correct > engineering change order I will help with the draft if you > require that. But for now I am DELETING all this mail on > killing SLs entirely it will not happen. Though they should > die and all should use globals the next best thing is to put > controls on this mess until we understand how to do it. > > /jim > [In matters of style, swim with the currents....in matters of > principle, stand like a rock. - Thomas Jefferson] > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Wednesday, October 30, 2002 4:01 PM > > To: 'Tim Hartrick'; ipng@sunroof.eng.sun.com; richdr@microsoft.com > > Subject: RE: Limiting the Use of Site-Local > > > > > > Thank you! > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tim Hartrick > > > Sent: Tuesday, October 29, 2002 4:41 PM > > > To: ipng@sunroof.eng.sun.com; richdr@microsoft.com > > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > > > > > > > All, > > > > > > I generally agree with all the points that Richard Draves > has made. > > > I am not as sanguine about the ease of implementation in > the network > > > stack but there is nothing in the details which is unimaginably > > > difficult. We very much need to move on. By my count this is the > > > forth or fifth time this topic has been debated and > redebated. Each > > > time the result has been the same. If every decision > taken by this > > > working group can be opened repeatedly by a noisy minority then > > > forward progress of any sort will not be possible. Consensus does > > > not require unanimity. No matter how noisy and persistent > > > the minority happens to be, it is possible to move on. > > > > > > There are a couple of other points I would like to make. > > > > > > Some folks seem to be operating under a misconception about RFC > > > 1918. RFC 1918 was a response to the rampant use of > arbitrary IPv4 > > > prefixes as private address space. The use of private > address space > > > was not a response to the publishing of RFC 1918. Network > > > administrators will use "private" IPv6 address space whether we > > > excise all mention of site-local addresses from the > specifications > > > or not. The network administrators that use private > address space > > > may be stupid, misinformed or have any number of socially > > > unacceptable habits but they still run their networks and > will run > > > their networks the way they see fit. Removing site-local addresses > > > from the architecture or attempting to restrict their use in > > > a way that is equivalent to removing them is an exercise in > > > futility absent better alternatives to site-local addresses. > > > > > > The burden on those that want to remove site-local > addresses is to > > > provide network administrators with an alternative which > meets their > > > needs but doesn't possess the negative aspects of site-local > > > addresses that are being railed against. The requirements that > > > network adminstrators would place on these addresses > would probably > > > be that there is no registration required and that the > addresses are > > > not globally routable. If such a proposal has been made > and it has > > > made it through last call of this working group, I must have > > > missed it. Contrary to what has been said by some in the > > > anti-site-local camp, the burden should be on them to come up > > > with alternatives to site-local addresses. Until those > > > alternatives have been thoroughly vetted by this working > > > group the previous consensus should hold. > > > > > > Counter to what one might believe from reading my > comments above, I > > > don't like the architectural mess that has occured as a > consequence > > > of the use private addresses in IPv4. The difference > between me and > > > the anti-site- local camp is that I don't anticipate that network > > > administrators will stop using private address (IPv6 or > IPv4) unless > > > they are provided with good reasons not to use them. That means > > > solving renumbering, solving address shortage, artificial or > > > otherwise, providing the an alternative "private" address > > > scheme of the sort cited above and providing the great IPv6 > > > applications which their customers want but that break in the > > > presence of site-local addresses. If these things are done, > > > it won't be necessary to add a bunch of MUST NOTs into the > > > verbiage in various specifications. Site-local addresses and > > > all the associated problems will fall into the dustbin of > > > obsolescence. Absent these things, all the MUST NOTs in the > > > world won't prevent the use of site-local addresses or some > > > other form of IPv6 "private" address. > > > > > > Network administrators don't read RFCs for the MUST NOTs. > They read > > > them for the solutions they provide. If the MUST NOTs get in the > > > way of the solution then they get ignored. > > > > > > > > > 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 > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:24:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNOA29017675; Wed, 30 Oct 2002 15:24:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNOASB017674; Wed, 30 Oct 2002 15:24:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNO729017667 for ; Wed, 30 Oct 2002 15:24:07 -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 g9UNOEbB016705 for ; Wed, 30 Oct 2002 15:24:15 -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 QAA14457 for ; Wed, 30 Oct 2002 16:24:09 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA22944; Wed, 30 Oct 2002 15:23:51 -0800 (PST) Message-Id: <5.1.0.14.2.20021030182051.07aa7500@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 18:25:08 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Keith Moore" , , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3DC@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, You have made a statement that the use of IPv6 site-local addresses (as opposed to globally-unique addresses) will increase the security of a private network. And, I still don't understand the basis for that claim. Could you please answer the following question that I posted earlier? >Let me turn the question around... You have posited that the >use of site-local address is somehow more "secure" than using >a private global address range that is filtered in the router. >Why? What attacks would work in the latter case that wouldn't >work in the former case? Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:24:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNOH29017685; Wed, 30 Oct 2002 15:24:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNOHdb017684; Wed, 30 Oct 2002 15:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNOC29017677 for ; Wed, 30 Oct 2002 15:24:12 -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 g9UNOKMq013150 for ; Wed, 30 Oct 2002 15:24:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06163 for ; Wed, 30 Oct 2002 15:24:14 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA22935; Wed, 30 Oct 2002 15:23:48 -0800 (PST) Message-Id: <5.1.0.14.2.20021030181900.07a95030@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 18:19:48 -0500 To: Mark Smith From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: Richard Draves , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <1036018549.7840.321.camel@dupy> References: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >On a related topic, if I was to stuff up my site local filters at the >edge of my site, would my network then become part of my ISPs site local >network ? In the proposed site-local models, are sites adjacent, or are >they separated by segments that only have a global address assignments >(eg the BGP AS model vs the OSPF area model) ? Adjacent, with the border running through the router. Also, all interfaces are considered to be in exactly one scope of each zone, so all interface are in exactly one site. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:25:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNP329017722; Wed, 30 Oct 2002 15:25:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNP3RH017721; Wed, 30 Oct 2002 15:25:03 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNOx29017714 for ; Wed, 30 Oct 2002 15:24: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 g9UNP7Mq013408 for ; Wed, 30 Oct 2002 15:25: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 PAA12421 for ; Wed, 30 Oct 2002 15:25:02 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 15:25:02 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3DB@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAWVeDAkqp6ijoRD6A5y9yYKkKYQAAFueQ From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UNP029017715 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > Let me turn the question around... You have posited > that the use of site-local address is somehow more > "secure" than using a private global address range > that is filtered in the router. Why? What attacks > would work in the latter case that wouldn't work in > the former case? I consider more secure if there is one more box to hack in order to compromise the network. Example: A host has been compromised by installing a piece of software that reads records from a database and "tunnels" the data out by embedding it in dummy http requests sent to a special http server. No firewall that I know of will catch this, so you prevent that host form accessing the outside by configuring an access-list somewhere denying http access to the outside. a) the host has a PA address: remove that access-list, and your little Trojan is ready to dump all the data out. b) the host has a site-local address: Now you need something else, another tunnel. You still need the Trojan to "tunnel" the database information into http requests, but now you also need something like a GRE or IPIP tunnel to tunnel the site-local addresses into PA. Every security architect that's worth its weigh in dung will design the network in such a way that the router that would be a good candidate to configure a tunnel (most likely the SBR) on is not the same that the one that holds the access-list, they are not administered by the same personnel who have been explicitly promised court martial and jail if they ever leak a password to a colleague. One more device to hack, more work for the hacker, more secure. Not to mention that in many cases the edge device is a Cisco, which means for most mortal hackers that their choice in tunnel types is limited by what is available in IOS, which in turn means that it will be doable to block these tunnels in the upstream firewall, which in turns means that the firewall itself will have to be hacked as well. Yet another device to hack, even more work for the hacker, even more secure. Another reason why site-local addresses are more secure: The hacking requires more skill than removing an access-list. Remember, hacking is mostly done from the inside. There is nothing the security engineer can do to prevent a spy to be hired as a network engineer, that's why there are security clearances. However, there is something that the security engineer can do, is to make the job of the janitor-turned-spy impossible by requiring a level of skill that he does not have. It's one thing to get someone to memorize a command to type when nobody looks, it's another thing to get someone to configure a router. Conclusion: If configured properly, a network that implements site-locals is more work for the hacker, and also requires a level of hacking skill that is above acquiring the password of a router and typing "no ip access-group xyz". Margaret, we have been having this kind of discussion since 1993 when RFC 1597 was being written. Also, read please read Tim Hartrick and Richard Draves' excellent (as always) posts. 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 Oct 30 15:27:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNRw29017846; Wed, 30 Oct 2002 15:27:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNRvns017845; Wed, 30 Oct 2002 15:27:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNRs29017838 for ; Wed, 30 Oct 2002 15:27:54 -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 g9UNS2Mq014425 for ; Wed, 30 Oct 2002 15:28:02 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14296 for ; Wed, 30 Oct 2002 15:27:57 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E3E2B18E2 for ; Wed, 30 Oct 2002 18:27:55 -0500 (EST) Date: Wed, 30 Oct 2002 18:27:55 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <200210302220.g9UMKsBM066922@drugs.dv.isc.org> References: <5.1.0.14.2.20021030164823.00a95080@mail.windriver.com> <200210302220.g9UMKsBM066922@drugs.dv.isc.org> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021030232755.E3E2B18E2@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Thu, 31 Oct 2002 09:20:54 +1100, Mark Andrews wrote: > > This is tunnel vision. The only reason that no one expects > them in the DNS is that we havn't added support for them > in the DNS. > > I think LL (and SL) should be in the DNS. Doing this actually > simplifies things. Only if you then revise all the application programs to let you specify the scope ID that provides the context for the name, whether the scope ID is represented as a DNS name or not. Please think about this for a minute. It's bad enough for applications that are driven by a human who can type or click or whatever from a list of possible scopes, but what do you do for programs like MTAs? If you're longing for a return to the days of fee!fie%foe@fum email addresess (or even SRA@XX.LCS.MIT.EDU.#Chaos), you're on the right road. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:30:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNUB29017929; Wed, 30 Oct 2002 15:30:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNUB3m017928; Wed, 30 Oct 2002 15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNU829017918 for ; Wed, 30 Oct 2002 15:30:08 -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 g9UNUGbB018531 for ; Wed, 30 Oct 2002 15:30:16 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15477 for ; Wed, 30 Oct 2002 15:30:09 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9UNU5BM067282 for ; Thu, 31 Oct 2002 10:30:05 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210302330.g9UNU5BM067282@drugs.dv.isc.org> To: ipng@sunroof.eng.sun.com Reply-to: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 17:54:39 CDT." <200210302254.g9UMsd006434@astro.cs.utk.edu> Date: Thu, 31 Oct 2002 10:30:05 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is tunnel vision. The only reason that no one expects > them in the DNS is that we havn't added support for them > in the DNS. > > well, that and the minor consideration that current DNS architecture > assumes that names are global and that queries return consistent results > everywhere. So. I've shown how to add them and return consistent results everywhere. The only reason we don't do it now is that we havn't added support to do it. Did you bother to actually read what I have posted in the last couple of days? Your responses to this and previous mail make me think that you are not actually paying attention to what is being sent. Rather you are locked in a crusade to kill SL and are ignoring anything which will actually address the problems you raise. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:30:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNUq29017979; Wed, 30 Oct 2002 15:30:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNUq0i017978; Wed, 30 Oct 2002 15:30:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNUn29017971 for ; Wed, 30 Oct 2002 15:30: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 g9UNUvbB018786 for ; Wed, 30 Oct 2002 15:30:57 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15847 for ; Wed, 30 Oct 2002 15:30:51 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA27509; Wed, 30 Oct 2002 23:30:47 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Jun-ichiro itojun Hagino Cc: "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <20021030214740.B731F7B9@starfruit.itojun.org> From: Ole Troan Date: Wed, 30 Oct 2002 23:30:47 +0000 In-Reply-To: <20021030214740.B731F7B9@starfruit.itojun.org> (Jun-ichiro itojun Hagino's message of "Thu, 31 Oct 2002 06:47:40 +0900") Message-ID: <7t5pttry060.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> A router might (and probably should) be hard-coded not to >>> forward link-local packets, as there is no reason to ever >>> forward them. >>> >>> However, a router that might ever need have multiple >>> interfaces in a single site can't be hard-coded not to >>> forward site-locals. Whether or not they will be forwarded is >>> the result of configuration. >> >>Actually, a router can forward link-locals between interfaces on the >>same link. In particular, a router can forward a packet with link-local >>dest and/or source back out the interface from which it arrived (and >>presumably generate a Redirect too). >> >>If you are implementing link-locals properly, it's really very little >>additional code to support site-locals. At least that's my experience. > > could you comment on routing code? (RIPng, OSPFv3) i still think > it's way too tough to support multi-sited node. RIPng is relatively simple. link-state protocols require congruent areas and sites. there are some open issues with regards to multicast and PIM I believe. routing protocol support is required in any case for VPNs. site-locals can be used without multi-site support, i.e treated pretty much like globals. multi-sited-ness shouldn't be recommended for other reasons than adding complexity to routers, e.g DNS issues. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 15:56:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNuV29018439; Wed, 30 Oct 2002 15:56:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNuVVH018438; Wed, 30 Oct 2002 15:56:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNuS29018431 for ; Wed, 30 Oct 2002 15:56:28 -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 g9UNuZbB026238 for ; Wed, 30 Oct 2002 15:56:36 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25066 for ; Wed, 30 Oct 2002 16:56:29 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 15:56:35 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , "'Tim Hartrick'" , , Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 15:56:11 -0800 Message-ID: <083501c2806f$eca3fb10$4b194104@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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B641@tayexc13.americas.cpqcorp.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9UNuS29018432 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, The fundamental difference is the assumption about what is a reasonable network topology. It is absolutely wrong to turn off SL just because a global exists, because neighboring nodes on a single wire may have local policy to be globally visible or not. Insisting that SL gets turned off because one node on the wire needs a global creates a very unreasonable burden to manage access lists, particularly if that node moves around between segments that would otherwise have no global nodes. Again, I am sympathetic to the point that multi-party apps should refuse to refer a SL if any of the members has a global, but that is at best a BCP targeted at app developers. Tony > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Wednesday, October 30, 2002 3:17 PM > To: alh-ietf@tndh.net; Tim Hartrick; > ipng@sunroof.eng.sun.com; richdr@microsoft.com > Subject: RE: Limiting the Use of Site-Local > > > Tony and Tim, > > I agree with Tim about the flow. But I strongly support > Margarets idea to limit them today to not be part of domain > where global addresses exist as Margaret has clearly > articulated. Support for that is not a minority and not > rehash but putting some controls on an architectural part of > IPv6 that is not understood, widely implemented, or deployed > as product with express warranty that it can be used in > production networks. > > So keep it in the architecture and lets put a control on it > right now and move on. > > I am personally not going to participate any further I have > nothing else to say. > > P.S. Tim I emphatically do not agree with your views on 1918 > and I was here as you when it was developed. But I see no > point in kicking that > dead horse either. We simply do not agree. It is moot > point though I > do agree. > > P.S. Margaret if we can get folks to do this correct > engineering change order I will help with the draft if you > require that. But for now I am DELETING all this mail on > killing SLs entirely it will not happen. Though they should > die and all should use globals the next best thing is to put > controls on this mess until we understand how to do it. > > /jim > [In matters of style, swim with the currents....in matters of > principle, stand like a rock. - Thomas Jefferson] > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Wednesday, October 30, 2002 4:01 PM > > To: 'Tim Hartrick'; ipng@sunroof.eng.sun.com; richdr@microsoft.com > > Subject: RE: Limiting the Use of Site-Local > > > > > > Thank you! > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tim Hartrick > > > Sent: Tuesday, October 29, 2002 4:41 PM > > > To: ipng@sunroof.eng.sun.com; richdr@microsoft.com > > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > > > > > > > All, > > > > > > I generally agree with all the points that Richard Draves > has made. > > > I am not as sanguine about the ease of implementation in > the network > > > stack but there is nothing in the details which is unimaginably > > > difficult. We very much need to move on. By my count this is the > > > forth or fifth time this topic has been debated and > redebated. Each > > > time the result has been the same. If every decision > taken by this > > > working group can be opened repeatedly by a noisy minority then > > > forward progress of any sort will not be possible. Consensus does > > > not require unanimity. No matter how noisy and persistent > > > the minority happens to be, it is possible to move on. > > > > > > There are a couple of other points I would like to make. > > > > > > Some folks seem to be operating under a misconception about RFC > > > 1918. RFC 1918 was a response to the rampant use of > arbitrary IPv4 > > > prefixes as private address space. The use of private > address space > > > was not a response to the publishing of RFC 1918. Network > > > administrators will use "private" IPv6 address space whether we > > > excise all mention of site-local addresses from the > specifications > > > or not. The network administrators that use private > address space > > > may be stupid, misinformed or have any number of socially > > > unacceptable habits but they still run their networks and > will run > > > their networks the way they see fit. Removing site-local addresses > > > from the architecture or attempting to restrict their use in > > > a way that is equivalent to removing them is an exercise in > > > futility absent better alternatives to site-local addresses. > > > > > > The burden on those that want to remove site-local > addresses is to > > > provide network administrators with an alternative which > meets their > > > needs but doesn't possess the negative aspects of site-local > > > addresses that are being railed against. The requirements that > > > network adminstrators would place on these addresses > would probably > > > be that there is no registration required and that the > addresses are > > > not globally routable. If such a proposal has been made > and it has > > > made it through last call of this working group, I must have > > > missed it. Contrary to what has been said by some in the > > > anti-site-local camp, the burden should be on them to come up > > > with alternatives to site-local addresses. Until those > > > alternatives have been thoroughly vetted by this working > > > group the previous consensus should hold. > > > > > > Counter to what one might believe from reading my > comments above, I > > > don't like the architectural mess that has occured as a > consequence > > > of the use private addresses in IPv4. The difference > between me and > > > the anti-site- local camp is that I don't anticipate that network > > > administrators will stop using private address (IPv6 or > IPv4) unless > > > they are provided with good reasons not to use them. That means > > > solving renumbering, solving address shortage, artificial or > > > otherwise, providing the an alternative "private" address > > > scheme of the sort cited above and providing the great IPv6 > > > applications which their customers want but that break in the > > > presence of site-local addresses. If these things are done, > > > it won't be necessary to add a bunch of MUST NOTs into the > > > verbiage in various specifications. Site-local addresses and > > > all the associated problems will fall into the dustbin of > > > obsolescence. Absent these things, all the MUST NOTs in the > > > world won't prevent the use of site-local addresses or some > > > other form of IPv6 "private" address. > > > > > > Network administrators don't read RFCs for the MUST NOTs. > They read > > > them for the solutions they provide. If the MUST NOTs get in the > > > way of the solution then they get ignored. > > > > > > > > > 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 > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Oct 30 16:00:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V00029018471; Wed, 30 Oct 2002 16:00:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9UNxx0L018470; Wed, 30 Oct 2002 15:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9UNxv29018463 for ; Wed, 30 Oct 2002 15:59: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 g9V004bB027287 for ; Wed, 30 Oct 2002 16:00:04 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05730 for ; Wed, 30 Oct 2002 16:59:58 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9UNxjBM067526; Thu, 31 Oct 2002 10:59:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210302359.g9UNxjBM067526@drugs.dv.isc.org> To: Rob Austein Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 18:27:55 CDT." <20021030232755.E3E2B18E2@thrintun.hactrn.net> Date: Thu, 31 Oct 2002 10:59:45 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At Thu, 31 Oct 2002 09:20:54 +1100, Mark Andrews wrote: > > > > This is tunnel vision. The only reason that no one expects > > them in the DNS is that we havn't added support for them > > in the DNS. > > > > I think LL (and SL) should be in the DNS. Doing this actually > > simplifies things. > > Only if you then revise all the application programs to let you > specify the scope ID that provides the context for the name, whether > the scope ID is represented as a DNS name or not. > > Please think about this for a minute. It's bad enough for > applications that are driven by a human who can type or click or > whatever from a list of possible scopes, but what do you do for > programs like MTAs? If you're longing for a return to the days of > fee!fie%foe@fum email addresess (or even SRA@XX.LCS.MIT.EDU.#Chaos), > you're on the right road. No Rob. I'm talking about 1 name with multiple addresses being returned in multiple scopes. I'm taking about having getaddrinfo() then filter out the inappropriate addresses using local knowledge and setting sin6_scope_id. This deals with 99.9% of address lookup. It allows you to have your printer in the DNS with SL and LL address and look it up by name (getaddrinfo()) without having to implement two faced DNS. It also allows you to lookup a remote print spooler with a only the GA's returned again by getaddrinfo(). If you want to see all the address which are outside your local scope you would do raw lookups or we could come up with an API that returned all the addresses with the scope information. sin6_scope_id is local to the machine so getaddrinfo() is not appropriate for this case. See Message-Id: <200210290019.g9T0JxBM025336@drugs.dv.isc.org> for details. Mark > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 16:00:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V00D29018486; Wed, 30 Oct 2002 16:00:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V00Dpk018485; Wed, 30 Oct 2002 16:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V00829018476 for ; Wed, 30 Oct 2002 16:00:08 -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 g9V00FbB027407 for ; Wed, 30 Oct 2002 16:00:16 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26708 for ; Wed, 30 Oct 2002 17:00:09 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 16:00:14 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 15:59:51 -0800 Message-ID: <083601c28070$6f7e5d00$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210302330.g9UNU5BM067282@drugs.dv.isc.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews wrote in response to Keith: > ... Your responses to this and previous > mail make me think that you are not actually paying attention > to what is being sent. Rather you are locked in a crusade > to kill SL and are ignoring anything which will actually > address the problems you raise. That summarizes it well. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 16:04:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V04d29018612; Wed, 30 Oct 2002 16:04:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V04cvB018611; Wed, 30 Oct 2002 16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V04S29018587; Wed, 30 Oct 2002 16:04:28 -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 g9V04ZbB029023; Wed, 30 Oct 2002 16:04:36 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08669; Wed, 30 Oct 2002 17:04:30 -0700 (MST) Message-ID: <027901c28070$dbde32e0$4a6015ac@T23KEMPF> From: "James Kempf" To: , Subject: FastRA RS Congestion Date: Wed, 30 Oct 2002 16:02:47 -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 A point was brought up on the list that in order to make FastRA defined in draft-mkahlil-fastra-01.txt work, the MAX_RTR_SOLICITATION_DELAY on the host must be set to zero and this would cause RS congestion if an access point failed or a group of mobile nodes moved at once. While this could be true on a wired link, on a wireless link it probably won't be true. For example, in 802.11, the first frame sent after handover is Authentication.Request(). If a group of mobile nodes moves at once, the CSMA/CA backoff on the link layer frames will space out the RSs sent after the authentication and reassociation process. For CDMA, the mobile nodes effectively have separate channels, and the radio resource management algorithms in the radio access network will assure that there is no collision. Generalization is always questionable, but since wireless is by nature a broadcast medium, the radio resource and link management algorithm typically have to take these kinds of situations into account. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 16:04:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V04X29018601; Wed, 30 Oct 2002 16:04:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V04V9i018598; Wed, 30 Oct 2002 16:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V04Q29018580 for ; Wed, 30 Oct 2002 16:04:26 -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 g9V04YMq026292 for ; Wed, 30 Oct 2002 16:04:34 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25401 for ; Wed, 30 Oct 2002 17:04:28 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id ED9CA3B371; Thu, 31 Oct 2002 11:04:25 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: Margaret Wasserman Cc: Richard Draves , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20021030181900.07a95030@mail.windriver.com> References: <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> <5.1.0.14.2.20021030171750.01b0ea50@mail.windriver.com> <5.1.0.14.2.20021030181900.07a95030@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 11:04:25 +1100 Message-Id: <1036022666.7840.353.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Tony, Margaret. On Thu, 2002-10-31 at 10:19, Margaret Wasserman wrote: > > > > >On a related topic, if I was to stuff up my site local filters at the > >edge of my site, would my network then become part of my ISPs site local > >network ? In the proposed site-local models, are sites adjacent, or are > >they separated by segments that only have a global address assignments > >(eg the BGP AS model vs the OSPF area model) ? > > Adjacent, with the border running through the router. > If this is the case, as a customer of a provider who wants to own and configure my own router, I'm individually responsible for ensuring my site local traffic doesn't leak into my provider's site local network, and vice versa. While my security is certainly my primary concern, surely my provider is not going to trust me to hold their internal site local security as a primary concern as well ? Its likely that don't even want me to see their site local routes at all. Also, Tony suggested that if I stuffed up my site local filtering, both myself and my provider would have to make an error with our IGP configuration for our sites to be joined. However, if the site boundary falls across a single router, then only one party has to make an EGP / IGP route distribution configuration error, and in my above example that could be me. I don't think my provider is going to like (and accept) that at all. > Also, all interfaces are considered to be in exactly one scope of > each zone, so all interface are in exactly one site. > I'm guessing you mean an interface can only be in only one site at a time, but not necessarily all members of the same site. Thanks, Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 16:30:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Uh29019227; Wed, 30 Oct 2002 16:30:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V0UgMF019226; Wed, 30 Oct 2002 16:30:42 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Ud29019219 for ; Wed, 30 Oct 2002 16:30:39 -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 g9V0UlMq003828 for ; Wed, 30 Oct 2002 16:30:47 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11333 for ; Wed, 30 Oct 2002 16:30:42 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1AB3F18E3 for ; Wed, 30 Oct 2002 19:30:41 -0500 (EST) Date: Wed, 30 Oct 2002 19:30:41 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <200210302359.g9UNxjBM067526@drugs.dv.isc.org> References: <20021030232755.E3E2B18E2@thrintun.hactrn.net> <200210302359.g9UNxjBM067526@drugs.dv.isc.org> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021031003041.1AB3F18E3@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Thu, 31 Oct 2002 10:59:45 +1100, Mark Andrews wrote: > > I'm talking about 1 name with multiple addresses being > returned in multiple scopes. I'm taking about having > getaddrinfo() then filter out the inappropriate addresses > using local knowledge and setting sin6_scope_id. Via this mapping table thingie, which I suppose we could configure easily enough using DHCPv6. So what happens when the mapping table isn't configured, is misconfigured, or somebody passes a raw scoped IP address into some other scope? > See Message-Id: <200210290019.g9T0JxBM025336@drugs.dv.isc.org> > for details. I read it. I even replied to it. I think it's a fine solution to one aspect of a more fundamental problem, and I remain unconvinced that the more fundamental problem is worth solving. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 16:33:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Xf29019269; Wed, 30 Oct 2002 16:33:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V0XfJe019268; Wed, 30 Oct 2002 16:33:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Xb29019255 for ; Wed, 30 Oct 2002 16:33:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V0XjMq004799 for ; Wed, 30 Oct 2002 16:33: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20265 for ; Wed, 30 Oct 2002 16:33:40 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 16:33:38 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD28A@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAdOkyXkUdL4LPQM+JhTr2xp4ufwAABGHw From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V0Xb29019256 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Mark.Andrews wrote in response to Keith: >> ... Your responses to this and previous >> mail make me think that you are not actually paying >> attention to what is being sent. Rather you are >> locked in a crusade to kill SL and are ignoring >> anything which will actually address the problems >> you raise. > That summarizes it well. > Tony Ditto. 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 Oct 30 16:34:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Y129019290; Wed, 30 Oct 2002 16:34:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V0Y1J9019289; Wed, 30 Oct 2002 16:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V0Xw29019282 for ; Wed, 30 Oct 2002 16:33: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 g9V0Y5bB007364 for ; Wed, 30 Oct 2002 16:34:06 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10443 for ; Wed, 30 Oct 2002 17:34:00 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9V0XnQ1012677; Thu, 31 Oct 2002 01:33:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 01:33:49 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C4D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" Cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 01:33:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Are you saying that site-local traffic would start > > leaking outside the site and routed globally? > > As in transient ISPs will just forward it? > > Of course the ISP's will forward them -- they (probably) > haven't been > configured to be part of any sites => Forward them where?? I can't imagine BGP not filtering SLs coming from the downstream customers. Regardless of what the spec says. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:01:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V11Z29019639; Wed, 30 Oct 2002 17:01:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V11Zkw019638; Wed, 30 Oct 2002 17:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V11V29019631 for ; Wed, 30 Oct 2002 17:01:31 -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 g9V11dbB015060 for ; Wed, 30 Oct 2002 17:01:39 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03926 for ; Wed, 30 Oct 2002 18:01:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V11W007088 for ; Wed, 30 Oct 2002 20:01:32 -0500 (EST) Message-Id: <200210310101.g9V11W007088@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 10:30:05 +1100.") <200210302330.g9UNU5BM067282@drugs.dv.isc.org> Date: Wed, 30 Oct 2002 20:01:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This is tunnel vision. The only reason that no one expects > > them in the DNS is that we havn't added support for them > > in the DNS. > > > > well, that and the minor consideration that current DNS architecture > > assumes that names are global and that queries return consistent results > > everywhere. > > So. I've shown how to add them and return consistent results > everywhere. The only reason we don't do it now is that we > havn't added support to do it. adding support to applications to deal with address scopes is an extremely nontrivial task. but feel free to start on it. when you're done, let the rest of us know. forgive us if those of us who don't believe that all of this complexity is justified don't help out. > Did you bother to actually read what I have posted in the > last couple of days? Your responses to this and previous > mail make me think that you are not actually paying attention > to what is being sent. Rather you are locked in a crusade > to kill SL and are ignoring anything which will actually > address the problems you raise. no, I'm in a crusade to make IPv6 suitable for applications. and I'm ignoring handwaving about the ease of making sweeping changes to accomodate needless complexity. If we can justify SLs on non-isolated networks at all then I'm happy to consider ways of putting them in DNS - anything is better than putting them in ordinary IN AAAA records. But putting SLs in the DNS doesn't solve the problems they cause. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:04:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V14H29019683; Wed, 30 Oct 2002 17:04:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V14HOW019682; Wed, 30 Oct 2002 17:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V14E29019675 for ; Wed, 30 Oct 2002 17:04:14 -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 g9V14MbB015870 for ; Wed, 30 Oct 2002 17:04:22 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25095 for ; Wed, 30 Oct 2002 18:04:15 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9V143BM067852; Thu, 31 Oct 2002 12:04:03 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210310104.g9V143BM067852@drugs.dv.isc.org> To: Rob Austein Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 19:30:41 CDT." <20021031003041.1AB3F18E3@thrintun.hactrn.net> Date: Thu, 31 Oct 2002 12:04:03 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At Thu, 31 Oct 2002 10:59:45 +1100, Mark Andrews wrote: > > > > I'm talking about 1 name with multiple addresses being > > returned in multiple scopes. I'm taking about having > > getaddrinfo() then filter out the inappropriate addresses > > using local knowledge and setting sin6_scope_id. > > Via this mapping table thingie, which I suppose we could configure > easily enough using DHCPv6. So what happens when the mapping table > isn't configured, is misconfigured, or somebody passes a raw scoped IP > address into some other scope? If it isn't configured you get globals only. Misconfigurations are undefined. A raw scoped address without scope is meaningless unless the host is single homed (LL) or single site (SL). Hopefully the kernel will reject messages sent to ambigous address (sin6_scope_id == 0). The kernel is in the position to determine whether the node is single homed or single sited. > > See Message-Id: <200210290019.g9T0JxBM025336@drugs.dv.isc.org> > > for details. > > I read it. I even replied to it. I think it's a fine solution to one > aspect of a more fundamental problem, and I remain unconvinced that > the more fundamental problem is worth solving. Fare enough. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:11:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1B929019791; Wed, 30 Oct 2002 17:11:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V1B945019790; Wed, 30 Oct 2002 17:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1B529019783 for ; Wed, 30 Oct 2002 17:11:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V1BDbB017747 for ; Wed, 30 Oct 2002 17:11:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08859 for ; Wed, 30 Oct 2002 18:11:07 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V1B0007145; Wed, 30 Oct 2002 20:11:02 -0500 (EST) Message-Id: <200210310111.g9V1B0007145@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: alh-ietf@tndh.net, "Tim Hartrick" , ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 18:23:09 EST.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE97C1@tayexc13.americas.cpqcorp.net> Date: Wed, 30 Oct 2002 20:11:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would also ask all those who want to kill SLs turn your support to > Margaret to put the controls on. Yes, this is the position I support. Even I do not expect to kill SLs in the sense that we would reallocate those addresses for other purposes, forbid using them under all conditions, expect routers to always filter them or hosts to always ignore them, etc. I don't like pulling the rug out from under people who have built designs around them, even if I think their designs are shortsighted and/or naive. I do however think we need to discourage use of SLs except in isolated networks. I also think we need to make it clear that in general applications aren't expected to work in the presence of a mixture of scoped and global addresses. Applications should treat SLs exactly like global addresses. Finally I think we need to discourage the idea that SLs are a security mechanism, because SL filters are at best only marginally better than other kinds of address filters (and I'm being charitable there). Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:11:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1Bp29019832; Wed, 30 Oct 2002 17:11:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V1BpL9019831; Wed, 30 Oct 2002 17:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1Bk29019824 for ; Wed, 30 Oct 2002 17:11: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 g9V1BtMq015393 for ; Wed, 30 Oct 2002 17:11:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01275 for ; Wed, 30 Oct 2002 17:11:49 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V1Bl007160; Wed, 30 Oct 2002 20:11:47 -0500 (EST) Message-Id: <200210310111.g9V1Bl007160@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 15:59:51 PST.") <083601c28070$6f7e5d00$4b194104@eagleswings> Date: Wed, 30 Oct 2002 20:11:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That summarizes it well. and it appears to me that you are trying to attack me personally rather than actually make credible arguments in favor of using SL. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:20:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1KM29020018; Wed, 30 Oct 2002 17:20:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V1KMXP020017; Wed, 30 Oct 2002 17:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1KI29020010 for ; Wed, 30 Oct 2002 17:20: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 g9V1KQbB020109 for ; Wed, 30 Oct 2002 17:20:26 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05188 for ; Wed, 30 Oct 2002 17:20:21 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V1Il007225; Wed, 30 Oct 2002 20:18:47 -0500 (EST) Message-Id: <200210310118.g9V1Il007225@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 10:59:45 +1100.") <200210302359.g9UNxjBM067526@drugs.dv.isc.org> Date: Wed, 30 Oct 2002 20:18:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm talking about 1 name with multiple addresses being returned in multiple scopes. I'm taking about having getaddrinfo() then filter out the inappropriate addresses using local knowledge and setting sin6_scope_id. This deals with 99.9% of address lookup. No, Mark, it doesn't, because the party that calls getaddrinfo isn't necessarily the same as the party (and doesn't share the same scopes as the party) that uses the addressees. there are numerous good reasons that many apps do NOT do a DNS lookup each time they want to contact another host. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:25:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1PW29020096; Wed, 30 Oct 2002 17:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V1PWU0020095; Wed, 30 Oct 2002 17:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1PT29020088 for ; Wed, 30 Oct 2002 17:25: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 g9V1PbMq018739 for ; Wed, 30 Oct 2002 17:25:37 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07839 for ; Wed, 30 Oct 2002 17:25:32 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2693F18E3 for ; Wed, 30 Oct 2002 20:25:31 -0500 (EST) Date: Wed, 30 Oct 2002 20:25:31 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-Reply-To: <7t5y98fy18g.fsf@mrwint.cisco.com> References: <3DC028E1.4060605@nc.rr.com> <7t5y98fy18g.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021031012531.2693F18E3@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What Ole said. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 17:29:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1Tn29020185; Wed, 30 Oct 2002 17:29:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V1Tm3l020184; Wed, 30 Oct 2002 17:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V1Ti29020177 for ; Wed, 30 Oct 2002 17:29:45 -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 g9V1TrbB022408 for ; Wed, 30 Oct 2002 17:29:53 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18962 for ; Wed, 30 Oct 2002 17:29:47 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V1Th007249; Wed, 30 Oct 2002 20:29:43 -0500 (EST) Message-Id: <200210310129.g9V1Th007249@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Bound, Jim'" , "'Tim Hartrick'" , ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 15:56:11 PST.") <083501c2806f$eca3fb10$4b194104@eagleswings> Date: Wed, 30 Oct 2002 20:29:43 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The fundamental difference is the assumption about what is a reasonable > network topology. It is absolutely wrong to turn off SL just because a > global exists, because neighboring nodes on a single wire may have local > policy to be globally visible or not. it is absolutely wrong to expect apps to deal with a mixture of SLs and globals, because that forces those apps to develop their own addressing and routing schemes, essentially making any notion of SL to indicate 'policy' irrelevant. > Insisting that SL gets turned off > because one node on the wire needs a global creates a very unreasonable > burden to manage access lists, particularly if that node moves around > between segments that would otherwise have no global nodes. well, I'd probably agree with that, because it provides an easy way to attack an isolated network that was legitimately using SLs. still, a network that is using globals shouldn't be using SLs. > Again, I am sympathetic to the point that multi-party apps should refuse > to refer a SL if any of the members has a global, but that is at best a > BCP targeted at app developers. it would never get published as a BCP because it's not a good practice to recommend - first because the app has no way of knowing in advance whether any of its (current or future) members has a global, and second because this prevents referrals between hosts in the same scope from going through an intermediary that doesn't share the same scope. in other words, it forces apps to know about topology. and for similar reasons that it's not okay for SLs on the net to fail when they happen to see a global, neither is it okay for apps to start refusing to refer SLs when they see a global. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:04:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V24f29020564; Wed, 30 Oct 2002 18:04:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V24fXQ020563; Wed, 30 Oct 2002 18:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V24c29020556 for ; Wed, 30 Oct 2002 18:04:38 -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 g9V24kbB001039 for ; Wed, 30 Oct 2002 18:04:46 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25054 for ; Wed, 30 Oct 2002 18:04:40 -0800 (PST) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V24Tur023146; Wed, 30 Oct 2002 21:04:30 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 21:03:48 -0500 Message-ID: <3DC08F14.3030709@nc.rr.com> Date: Wed, 30 Oct 2002 21:01:56 -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: Jun-ichiro itojun Hagino CC: Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <20021030214740.B731F7B9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > could you comment on routing code? (RIPng, OSPFv3) i still think > it's way too tough to support multi-sited node. Not that the chairs have finalized the agenda, but I am planning on presenting what it took me to get a site-border router coded and running. If you want to request a certain level of detail, let me know. 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 Oct 30 18:16:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2GM29020794; Wed, 30 Oct 2002 18:16:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2GMdJ020793; Wed, 30 Oct 2002 18:16:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2GH29020786 for ; Wed, 30 Oct 2002 18:16:17 -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 g9V2GPbB003581 for ; Wed, 30 Oct 2002 18:16:25 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06332 for ; Wed, 30 Oct 2002 19:16:19 -0700 (MST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V2FmiZ029924; Wed, 30 Oct 2002 21:15:48 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 21:16:20 -0500 Message-ID: <3DC091D1.7010405@nc.rr.com> Date: Wed, 30 Oct 2002 21:13:37 -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: alh-ietf@tndh.net CC: "'Mark Smith'" , "'Margaret Wasserman'" , "'Richard Draves'" , "'Keith Moore'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <082901c28069$6b1a6ad0$4b194104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > Mark Smith wrote: > >>... >>On a related topic, if I was to stuff up my site local >>filters at the edge of my site, would my network then become >>part of my ISPs site local network ? > > > You would both have to make an error to get the two IGPs tied together. > > >>In the proposed >>site-local models, are sites adjacent, or are they separated >>by segments that only have a global address assignments (eg >>the BGP AS model vs the OSPF area model) ? > > > I remember this discussion a few months back, but I don't remember the > conclusion. Maybe Ole does. The following is a proposal that was discussed amongst the scoped addr arch authors and the ADs. This model would address the issue of having adjacent sites quite nicely. -- -- --| |-----------| |-- -- -- <--site 1--> <-dummy site-> <-- site 2 --> 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 Oct 30 18:14:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Eu29020760; Wed, 30 Oct 2002 18:14:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2EuNa020759; Wed, 30 Oct 2002 18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Eq29020752 for ; Wed, 30 Oct 2002 18:14:53 -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 g9V2F0bB003152 for ; Wed, 30 Oct 2002 18:15:00 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10339 for ; Wed, 30 Oct 2002 19:14:55 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 18:14:54 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD28B@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAYzicqMpiW9faTQOHrKffDtg20wAE2YQw From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V2Er29020753 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, >> Michel Py wrote: >> Now, explain me how you design that network (the plane) >> with deprecating site-locals when global addresses are >> present. Modern plane designs are multiple redundant >> networks that carry data for almost all of the plane's >> devices. > Dan Lanciani wrote: > Presumably you are supposed to get a global address for > the rudder controller and hope that the FAA implements > a no-renumbering-in-flight rule. The rest of us with > less critical applications will probably just have to > make do with unstable addresses. Ridiculous, IMHO. That's the kind of thing scoped addresses were invented in the first place. > The thing that bothers me about this discussion is that > it is starting to sound as if site-local addressing (and > all the endless debate about scope and address selection > rules) was just another sham like transparent renumbering. > Until a few days ago site-local addresses (along with the > scope baggage they entail) were a part of the IPv6 vision. Allow me to correct you: site-local are part of the IPv6 vision until further notice, as they have been since longer than I can remember without looking up references. I don't question the right of discussing it all over again, but a few agitated members does not equate WG consensus, less a new document without SLs. I am sure that Margaret will, as she did in the past, put her personal views aside and act as chair in the direction that the WG has previously reached consensus on, which is that site-local are indeed part of the IPv6 vision and that there is absolutely no consensus whatsoever to change this. I wonder what Steeve Deering would have said about this? Sounds like a Monica strike to me. > Now suddenly they are a minor wart to be eliminated, and > all roads seem to lead back to the situation where the > stability (and cost) of your internal network is directly > dependent on your ISP. This in turn will almost certainly > result in the introduction of IPv6 NAT and we will be right > back where we started. I share your concerns, and that would almost certainly trigger random prefix hijacking that, when leaking, will be harder to spot than announcements of FEC0::/10 in the defaultless table. 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 Oct 30 18:22:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2M129020901; Wed, 30 Oct 2002 18:22:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2M1gF020900; Wed, 30 Oct 2002 18:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Lw29020893 for ; Wed, 30 Oct 2002 18:21:58 -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 g9V2M6Mq005118 for ; Wed, 30 Oct 2002 18:22:06 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08454 for ; Wed, 30 Oct 2002 19:22:01 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 18:21:59 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 18:21:59 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 18:22:00 -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: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 18:21:58 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcJ/ikX2kKfAoxp5QmeS6POa1yIRuAA7YBmg From: "Brian Zill" To: "Keith Moore" Cc: X-OriginalArrivalTime: 31 Oct 2002 02:22:00.0542 (UTC) FILETIME=[4B3247E0:01C28084] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V2Lw29020894 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore writes: > >>>> Brian Zill writes: >>>> One advantage of having scoped addresses defined >>>> in the IPv6 architecture from the start is that >>>> applications can know not to pass them outside >>>> of their scope. >>> >>> NO. >>> >>> 1. applications don't know where their scope ends. >> >> They don't need to. If they are communicating with >> another entity via a site-local address, then that >> entity is by definition within scope. > > that doesn't mean that the entity that will end up > using the address is within scope. If the entity in question wants to pass the address on, it needs to follow the same rule. This keeps scoped addresses contained within the scope where they are valid. > where do you get the idea that all referrals are > one hop? I didn't say they were, and I thought most people would easily figure out the point I made above. > furthermore it's wrong (or at least incomplete) because a > host can have access to multiple scopes. Of course. But the scope boundary is exposed to the application via the scope-id in the sockaddrs it is using. If it receives a site-local address via one channel (say where the site-local sockaddr has scope-id X) then it can't pass it on to another entity via a different channel if that channel is using a site-local sockaddr with scope-id != X. >> Therefore they can legitimately pass a site-local >> address in the data stream to that entity. Otherwise, >> they can't. Very simple and straight-forward. > >it's simple, straight-forward -- and incorrect. On the contrary, I've shown where it is correct. You have failed to justify your accusation. >>> 2. expecting applications to know about network >>> topology drastically increases their complexity >>> without any recognizable benefits. >> >> As noted above, the applications don't need to know >> anything about the network topology, they only need >> to know what kind of addresses they are using. > >False. there's no way that a referrer can know what >scopes the party to which the addresses are being >referred has access to. the best the referrer can do >is refer all available addresses. even then, without >global scope IDs we don't have a way for the party >using those referrals to know which addresses are valid >in the scopes to which it has access. No, as I've clearly shown above, an application can easily ensure that it only refers addresses which are meaningful to referee. Therefore, the receiving party will always get valid referrals. But this can only work if we have site-local addresses. If we force people to use random global address space as non-routable, then apps will have no choice but to blindly pass them around in the data stream (as I pointed out in my previous mail). >> If, however, random global address which happened >> not to be globally routable (due to firewalls/filters) >> were used, the app couldn't determine this, and could >> end up blindly passing these non-routable >> addresses around in the data stream. > >yes, Glad to see we agree on something :-) >but since the addresses are global the party that is >*using* the addresses has at least some chance of knowing >whether it has access to them. As I've shown above, proper use of site-locals solves this problem. If the party gets a site-local, it can use it. If we were to retreat to a world with only non-routable globals, it would have no such guarantee. Site-locals give the app much better than "some chance". >(for instance, does it have a route to that net?) And here I thought you were against apps needing to know about network topology? Most end-hosts have a default route to their first-hop router, that's it. They don't know anything more about what prefixes are reachable. Non-routable globals aren't the answer. Again, the solution I've outlined is simple, practical, and works today. --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 Oct 30 18:24:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2O429020945; Wed, 30 Oct 2002 18:24:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2O4rA020944; Wed, 30 Oct 2002 18:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2O129020934 for ; Wed, 30 Oct 2002 18:24:01 -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 g9V2O9Mq007060 for ; Wed, 30 Oct 2002 18:24:09 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27949 for ; Wed, 30 Oct 2002 19:24:03 -0700 (MST) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V2MVvL027507; Wed, 30 Oct 2002 21:23:54 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 21:09:56 -0500 Message-ID: <3DC09071.60706@nc.rr.com> Date: Wed, 30 Oct 2002 21:07:45 -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: Ole Troan CC: Jun-ichiro itojun Hagino , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <20021030214740.B731F7B9@starfruit.itojun.org> <7t5pttry060.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: >>>>A router might (and probably should) be hard-coded not to >>>>forward link-local packets, as there is no reason to ever >>>>forward them. >>>> >>>>However, a router that might ever need have multiple >>>>interfaces in a single site can't be hard-coded not to >>>>forward site-locals. Whether or not they will be forwarded is >>>>the result of configuration. >>> >>>Actually, a router can forward link-locals between interfaces on the >>>same link. In particular, a router can forward a packet with link-local >>>dest and/or source back out the interface from which it arrived (and >>>presumably generate a Redirect too). >>> >>>If you are implementing link-locals properly, it's really very little >>>additional code to support site-locals. At least that's my experience. >> >> could you comment on routing code? (RIPng, OSPFv3) i still think >> it's way too tough to support multi-sited node. > > > RIPng is relatively simple. link-state protocols require congruent > areas and sites. there are some open issues with regards to multicast > and PIM I believe. routing protocol support is required in any case > for VPNs. The actual routing protocol changes in RIPng is dependent on how you structure your RIBs. I hacked RIPng to make an SBR using a monolithic RIB with an additional index (the zone id). It was an additional 800-900 lines of code to deal with figuring out which RIB entries needed to be advertised on each interface. Then there are the changes to configure and maintain the zone IDs. The biggest hit is actually in the forwarding. Each packet gets at least one additional table lookup (for the incoming zone id). Then there are the checks to ensure that the source address is valid (e.g. a site-local SA and global DA trying to cross a site border). The extra cost? Performance drops around 25-30% for a SBR between 3 sites. Of course, this was all software based, but even a hardware-based solution will take the extra lookup hits. 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 Oct 30 18:27:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2R929021070; Wed, 30 Oct 2002 18:27:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2R9a4021069; Wed, 30 Oct 2002 18:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2R629021061 for ; Wed, 30 Oct 2002 18:27: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 g9V2R9bB005910 for ; Wed, 30 Oct 2002 18:27:09 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00672 for ; Wed, 30 Oct 2002 19:27:03 -0700 (MST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V2QhiZ013030; Wed, 30 Oct 2002 21:26:43 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 21:27:14 -0500 Message-ID: <3DC09460.1050205@nc.rr.com> Date: Wed, 30 Oct 2002 21:24:32 -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: Rob Austein CC: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <3DC028E1.4060605@nc.rr.com> <7t5y98fy18g.fsf@mrwint.cisco.com> <20021031012531.2693F18E3@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For the record, my opinion follows Ole's comments. Brian Rob Austein wrote: > What Ole said. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 30 18:28:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Sn29021129; Wed, 30 Oct 2002 18:28:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2SnGr021128; Wed, 30 Oct 2002 18:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2S929021100 for ; Wed, 30 Oct 2002 18:28: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 g9V2SHbB006165 for ; Wed, 30 Oct 2002 18:28:17 -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 TAA10946 for ; Wed, 30 Oct 2002 19:28:11 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA04498; Wed, 30 Oct 2002 18:28:00 -0800 (PST) Message-Id: <5.1.0.14.2.20021030212644.032afec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 21:29:32 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Dan Lanciani" , In-Reply-To: <2B81403386729140A3A899A8B39B04640BD28B@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I wonder what Steeve Deering would have said about this? Sounds like a >Monica strike to me. What is a Monica strike? I am pretty sure that Steve would have told us, again, that relative addressing is an important part of any addressing scheme and that we need to have some sort of relative addressing scheme in IPv6. It is very unfortunate, though, that Steve is no longer here to help us figure out how to do it -- I'm not being sarcastic, I'd much prefer that he was here... So, we will have to figure out what to do without him. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:28:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2S229021099; Wed, 30 Oct 2002 18:28:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2S1VO021098; Wed, 30 Oct 2002 18:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Rw29021091 for ; Wed, 30 Oct 2002 18:27:58 -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 g9V2S6bB006116 for ; Wed, 30 Oct 2002 18:28:06 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15683 for ; Wed, 30 Oct 2002 19:27:59 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9V2RWBM068124; Thu, 31 Oct 2002 13:27:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210310227.g9V2RWBM068124@drugs.dv.isc.org> To: Keith Moore Cc: Rob Austein , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 20:18:47 CDT." <200210310118.g9V1Il007225@astro.cs.utk.edu> Date: Thu, 31 Oct 2002 13:27:32 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm talking about 1 name with multiple addresses being > returned in multiple scopes. I'm taking about having > getaddrinfo() then filter out the inappropriate addresses > using local knowledge and setting sin6_scope_id. > This deals with 99.9% of address lookup. > > No, Mark, it doesn't, because the party that calls getaddrinfo > isn't necessarily the same as the party (and doesn't share the same > scopes as the party) that uses the addressees. List the number of application thay just lookup a address then connect. Now list the number of applications that lookup a address for a third party. My bet is that the result will be over 1000 to 1. Also if you read the mail I admitted that there was a class of applictation where getaddrinfo() is not enough. That those applications would need a different API to look up the addresses (or call the DNS directly). However that class of application could still determine approriate remote SL to use by matching against the scope name in the SA6 record and returning the address along with the scope name. > there are numerous good reasons that many apps do NOT do a DNS lookup > each time they want to contact another host. Which is irrelevent as to whether a address is in the DNS or not. Mark > > Keith -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:32:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Wk29021313; Wed, 30 Oct 2002 18:32:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2WkhZ021312; Wed, 30 Oct 2002 18:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2Wg29021304 for ; Wed, 30 Oct 2002 18:32:43 -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 g9V2WoMq009042 for ; Wed, 30 Oct 2002 18:32:51 -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 TAA12677 for ; Wed, 30 Oct 2002 19:32:45 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 18:32:45 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD28D@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhUR1oc8bUNgQQ7mwxHMY+SuU5QAACJKA From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V2Wh29021306 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What is a Monica strike? A Monica strike is what Bill Clinton did a while ago: Make a lot of noise launching a bunch of cruise missiles at Saddam to try to get the people's attention away from the fact that he had a young lady under his desk. 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 Oct 30 18:38:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2cf29021565; Wed, 30 Oct 2002 18:38:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2cf1h021564; Wed, 30 Oct 2002 18:38:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2cc29021557 for ; Wed, 30 Oct 2002 18:38:38 -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 g9V2ckMq010035 for ; Wed, 30 Oct 2002 18:38:46 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03505 for ; Wed, 30 Oct 2002 19:38:40 -0700 (MST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V2cLiZ025951; Wed, 30 Oct 2002 21:38:21 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 30 Oct 2002 21:38:43 -0500 Message-ID: <3DC0971A.1080605@nc.rr.com> Date: Wed, 30 Oct 2002 21:36:10 -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: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <080e01c28059$59318f20$4b194104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, That is a reasonable approach and one that I could live with. It allows SLs to exist and control is based on tools that are in wide use today. Brian Tony Hain wrote: > The whole discussion about lack of definition of site boundary is bogus, > and causing a large waste of energy. We don't tell people how to bound > areas in OSPF, yet we are expected to spell out the universal definition > of a site. To a first order, the concepts are exactly the same, how much > information is exposed across administrative borders. > > An organization should probably start with the assumption that a site > boundary is exactly congruent with an OSPF area, but they may choose to > restrict it further, or expand it when it makes sense for their network. > In any case, the site boundary should never be larger than the IGP > scope, so if we are going to talk about defaults, rather than assuming > every interface is in a different site, why not assume every EGP/IGP > boundary identifies a different site? If we can get past that, maybe we > can start talking about area boundaries as a reasonable default. > > Tony > > > >>-----Original Message----- >>From: owner-ipng@sunroof.eng.sun.com >>[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Brian Haberman >>Sent: Wednesday, October 30, 2002 10:46 AM >>To: ipng@sunroof.eng.sun.com >>Subject: Default site-local behavior for routers >> >> >>So, one of the items that Margaret suggested was some text in >>the node requirements doc or the scoped addr arch that states >>that nodes default to being in one site. >> >>However, there has been some mention that people would prefer >>different behavior in routers. That is, the stated desire >>was that, by default, each interface on a router be in its own site. >> >>This suggestion leads to the model where hosts with multiple >>interfaces will assume that all its interfaces are in the >>same site (e.g. have the same site-local zone id) unless >>explicitly configured to have multiple sites. While routers >>will default to having a unique site-local zone id for each >>interface (thus rendering SLs to link-local behavior) unless >>explicitly configured to have multiple interfaces in the same site. >> >>This difference in behavior for hosts and routers leads to >>some interesting issues. One big one is how the site-local >>zone ids are setup and potentially changed when a host >>becomes a router or vice versa. >> >>What are others' opinions on this issue? >> >>Brian >> >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:46:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2kf29021690; Wed, 30 Oct 2002 18:46:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2keOG021689; Wed, 30 Oct 2002 18:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2kb29021682 for ; Wed, 30 Oct 2002 18:46:38 -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 g9V2kjMq011442 for ; Wed, 30 Oct 2002 18:46:46 -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 TAA17859 for ; Wed, 30 Oct 2002 19:46:40 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA12372; Wed, 30 Oct 2002 18:46:32 -0800 (PST) Message-Id: <5.1.0.14.2.20021030214629.02e58c10@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 21:47:05 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B04640BD28D@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Okay, so I am confused how it applies here. I'd be very surprised to learn that I have a young lady under my desk... Margaret At 09:32 PM 10/30/02, Michel Py wrote: > > What is a Monica strike? > >A Monica strike is what Bill Clinton did a while ago: Make a lot of >noise launching a bunch of cruise missiles at Saddam to try to get the >people's attention away from the fact that he had a young lady under his >desk. > >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 Oct 30 18:47:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2l729021710; Wed, 30 Oct 2002 18:47:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2l7GP021709; Wed, 30 Oct 2002 18:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2kx29021695 for ; Wed, 30 Oct 2002 18:46:59 -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 g9V2l7bB010348 for ; Wed, 30 Oct 2002 18:47:07 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08360 for ; Wed, 30 Oct 2002 19:47:00 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9V2kHBM068228; Thu, 31 Oct 2002 13:46:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210310246.g9V2kHBM068228@drugs.dv.isc.org> To: Keith Moore Cc: alh-ietf@tndh.net, "'Bound, Jim'" , "'Tim Hartrick'" , ipng@sunroof.eng.sun.com, richdr@microsoft.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Wed, 30 Oct 2002 20:29:43 CDT." <200210310129.g9V1Th007249@astro.cs.utk.edu> Date: Thu, 31 Oct 2002 13:46:17 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The fundamental difference is the assumption about what is a reasonable > > network topology. It is absolutely wrong to turn off SL just because a > > global exists, because neighboring nodes on a single wire may have local > > policy to be globally visible or not. > > it is absolutely wrong to expect apps to deal with a mixture of SLs and > globals, because that forces those apps to develop their own addressing > and routing schemes, essentially making any notion of SL to indicate > 'policy' irrelevant. 99.9% of applications just want a address to connect to. They don't care if it is a SL, LL or GA. For the other 0.1% being able see the scoped the hosts are in allows them to make sensible decisions. If you can't see the scopes you can't make the decisions. AAAA doesn't give you the information you need. SA6 will give you the information you need. > > Insisting that SL gets turned off > > because one node on the wire needs a global creates a very unreasonable > > burden to manage access lists, particularly if that node moves around > > between segments that would otherwise have no global nodes. > > well, I'd probably agree with that, because it provides an easy way to > attack an isolated network that was legitimately using SLs. still, > a network that is using globals shouldn't be using SLs. Well don't configure *your* network to do this. Stop trying to preventing those that do from doing so. > > Again, I am sympathetic to the point that multi-party apps should refuse > > to refer a SL if any of the members has a global, but that is at best a > > BCP targeted at app developers. > > it would never get published as a BCP because it's not a good practice > to recommend - first because the app has no way of knowing in advance > whether any of its (current or future) members has a global, and second > because this prevents referrals between hosts in the same scope from > going through an intermediary that doesn't share the same scope. > in other words, it forces apps to know about topology. Tunnel vision. > and for similar reasons that it's not okay for SLs on the net to fail > when they happen to see a global, neither is it okay for apps to start > refusing to refer SLs when they see a global. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:50:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2oB29021800; Wed, 30 Oct 2002 18:50:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2oB0t021799; Wed, 30 Oct 2002 18:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2o729021792 for ; Wed, 30 Oct 2002 18:50:07 -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 g9V2oFbB011149 for ; Wed, 30 Oct 2002 18:50:15 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24596 for ; Wed, 30 Oct 2002 18:50:10 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA13888; Wed, 30 Oct 2002 18:50:00 -0800 (PST) Message-Id: <5.1.0.14.2.20021030215038.02e5c880@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 21:51:35 -0500 To: Brian Haberman From: Margaret Wasserman Subject: Re: Default site-local behavior for routers Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <3DC0971A.1080605@nc.rr.com> References: <080e01c28059$59318f20$4b194104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >>In any case, the site boundary should never be larger than the IGP >>scope, so if we are going to talk about defaults, rather than assuming >>every interface is in a different site, why not assume every EGP/IGP >>boundary identifies a different site? If we can get past that, maybe we >>can start talking about area boundaries as a reasonable default. This works pretty well to bound the problem for routing protocols and routers. I'm not sure that it does much, though, to address the issues that site-locals raise for transport protocols, applications, DNS and management protocols. Am I missing something? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:51:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2pl29021880; Wed, 30 Oct 2002 18:51:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2pkM0021879; Wed, 30 Oct 2002 18:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2pd29021863 for ; Wed, 30 Oct 2002 18:51:39 -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 g9V2pkbB011556 for ; Wed, 30 Oct 2002 18:51:47 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08931 for ; Wed, 30 Oct 2002 19:51:40 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id CAA04272; Thu, 31 Oct 2002 02:51:38 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Brian Haberman Cc: Jun-ichiro itojun Hagino , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <20021030214740.B731F7B9@starfruit.itojun.org> <7t5pttry060.fsf@mrwint.cisco.com> <3DC09071.60706@nc.rr.com> From: Ole Troan Date: Thu, 31 Oct 2002 02:51:38 +0000 In-Reply-To: <3DC09071.60706@nc.rr.com> (Brian Haberman's message of "Wed, 30 Oct 2002 21:07:45 -0500") Message-ID: <7t58z0fcocl.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [...] > The biggest hit is actually in the forwarding. Each packet > gets at least one additional table lookup (for the incoming > zone id). Then there are the checks to ensure that the source > address is valid (e.g. a site-local SA and global DA trying > to cross a site border). you have to do the outgoing check for link-locals anyway. > The extra cost? Performance drops around 25-30% for a SBR > between 3 sites. Of course, this was all software based, > but even a hardware-based solution will take the extra lookup > hits. I don't see a performance drop in our implementation. an additional table lookup is not needed for forwarding. you need to figure out the scope of the DA of course, but that is needed for link-local/multicast anyway. cheers, Ole -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 18:52:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2qZ29021929; Wed, 30 Oct 2002 18:52:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V2qZRV021928; Wed, 30 Oct 2002 18:52:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V2qV29021921 for ; Wed, 30 Oct 2002 18:52:31 -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 g9V2qdMq012626 for ; Wed, 30 Oct 2002 18:52:39 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14106 for ; Wed, 30 Oct 2002 18:52:33 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id A4D0E3B371; Thu, 31 Oct 2002 13:52:30 +1100 (EST) Subject: Re: Limiting the Use of Site-Local From: Mark Smith To: Brian Haberman Cc: alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Richard Draves'" , "'Keith Moore'" , ipng@sunroof.eng.sun.com In-Reply-To: <3DC091D1.7010405@nc.rr.com> References: <082901c28069$6b1a6ad0$4b194104@eagleswings> <3DC091D1.7010405@nc.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 13:52:30 +1100 Message-Id: <1036032752.11151.391.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-10-31 at 13:13, Brian Haberman wrote: > > > Tony Hain wrote: > > Mark Smith wrote: > > > >>... > >>On a related topic, if I was to stuff up my site local > >>filters at the edge of my site, would my network then become > >>part of my ISPs site local network ? > > > > > > You would both have to make an error to get the two IGPs tied together. > > > > > >>In the proposed > >>site-local models, are sites adjacent, or are they separated > >>by segments that only have a global address assignments (eg > >>the BGP AS model vs the OSPF area model) ? > > > > > > I remember this discussion a few months back, but I don't remember the > > conclusion. Maybe Ole does. > > The following is a proposal that was discussed amongst the > scoped addr arch authors and the ADs. This model would address > the issue of having adjacent sites quite nicely. > > -- -- > --| |-----------| |-- > -- -- > > <--site 1--> <-dummy site-> <-- site 2 --> > > Brian Thanks Brian, that make sense, and clears up my concerns about a single router being the site-local security device for both the provider and the customer. Sorry if I'm asking dumb questions, I'm just thinking about how I might use site local addressing if I was to build an Australia wide IPv6 based enterprise network, interconnecting the main capital cities. As an example, I can see three different ways I could site-local address the 8 capital cities we have down here (for those who may not be aware, we have something like at least 500 kilometers between capital cities down here) : * site-local boundary at the edge of each city. wan links between cities would be treated as dummy sites as per your example above. * delete the dummy sites in the previous model, and extend the site-local boundary of one of the main sites out to the edge of all the other sites eg the Sydney site local addressing would finish at the edge of the Melbourne, Adelaide etc site local boundary * with 54 bits of subnet address space available in the site-local fec0::/10 address space, it would be very tempting to just treat the whole of Australia as one big site, and avoid site boundary routing configuration issues completely. Obviously my last two models don't really fit the idea that site-local addressing is to cover a single geographical site. Are there any documents / drafts / email threads that discuss various possible site local addressing / boundary models I can have a read of ? Thanks, Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 19:01:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V31e29022342; Wed, 30 Oct 2002 19:01:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V31e3E022341; Wed, 30 Oct 2002 19:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V31a29022334 for ; Wed, 30 Oct 2002 19:01: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 g9V31ibB013521 for ; Wed, 30 Oct 2002 19:01:44 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00214 for ; Wed, 30 Oct 2002 19:01:39 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA18248; Wed, 30 Oct 2002 19:01:15 -0800 (PST) Message-Id: <5.1.0.14.2.20021030220046.02e70b30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 22:02:49 -0500 To: Ole Troan From: Margaret Wasserman Subject: Re: Limiting the Use of Site-Local Cc: Brian Haberman , Jun-ichiro itojun Hagino , Richard Draves , ipng@sunroof.eng.sun.com In-Reply-To: <7t58z0fcocl.fsf@mrwint.cisco.com> References: <3DC09071.60706@nc.rr.com> <20021030214740.B731F7B9@starfruit.itojun.org> <7t5pttry060.fsf@mrwint.cisco.com> <3DC09071.60706@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I don't see a performance drop in our implementation. an additional >table lookup is not needed for forwarding. you need to figure out the >scope of the DA of course, but that is needed for link-local/multicast >anyway. The issue is that you also have to check the source address and drop the packet if you would be crossing a scope boundary for the source address... I think that a lot of routers already (in IPv4) have the capability of doing fast classification/filtering based on both source and destination addresses (among other things), so I don't know how much of a performance hit this will cause for a hardware-based routers. And, as was already pointed out, you need to do it for link-local addresses, anyway. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 19:07:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V37c29022436; Wed, 30 Oct 2002 19:07:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V37cxL022435; Wed, 30 Oct 2002 19:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V37Z29022428 for ; Wed, 30 Oct 2002 19:07:35 -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 g9V37hbB014687 for ; Wed, 30 Oct 2002 19:07:43 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15710 for ; Wed, 30 Oct 2002 20:07:36 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 5B39C3B371; Thu, 31 Oct 2002 14:07:35 +1100 (EST) Subject: Re: Default site-local behavior for routers From: Mark Smith To: Brian Haberman Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <3DC0971A.1080605@nc.rr.com> References: <080e01c28059$59318f20$4b194104@eagleswings> <3DC0971A.1080605@nc.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 14:07:35 +1100 Message-Id: <1036033655.7840.398.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Would "provider independent local addressing" be a better name for site local addressing if Tony's model is the most commonly followed ? I would find that a more descriptive name, as it doesn't suggest that I have to artificially place a boundary on the addressing due to physical geography. Mark. On Thu, 2002-10-31 at 13:36, Brian Haberman wrote: > Tony, > That is a reasonable approach and one that I could live > with. It allows SLs to exist and control is based on tools > that are in wide use today. > > Brian > > Tony Hain wrote: > > The whole discussion about lack of definition of site boundary is bogus, > > and causing a large waste of energy. We don't tell people how to bound > > areas in OSPF, yet we are expected to spell out the universal definition > > of a site. To a first order, the concepts are exactly the same, how much > > information is exposed across administrative borders. > > > > An organization should probably start with the assumption that a site > > boundary is exactly congruent with an OSPF area, but they may choose to > > restrict it further, or expand it when it makes sense for their network. > > In any case, the site boundary should never be larger than the IGP > > scope, so if we are going to talk about defaults, rather than assuming > > every interface is in a different site, why not assume every EGP/IGP > > boundary identifies a different site? If we can get past that, maybe we > > can start talking about area boundaries as a reasonable default. > > > > Tony > > > > > > > >>-----Original Message----- > >>From: owner-ipng@sunroof.eng.sun.com > >>[mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Brian Haberman > >>Sent: Wednesday, October 30, 2002 10:46 AM > >>To: ipng@sunroof.eng.sun.com > >>Subject: Default site-local behavior for routers > >> > >> > >>So, one of the items that Margaret suggested was some text in > >>the node requirements doc or the scoped addr arch that states > >>that nodes default to being in one site. > >> > >>However, there has been some mention that people would prefer > >>different behavior in routers. That is, the stated desire > >>was that, by default, each interface on a router be in its own site. > >> > >>This suggestion leads to the model where hosts with multiple > >>interfaces will assume that all its interfaces are in the > >>same site (e.g. have the same site-local zone id) unless > >>explicitly configured to have multiple sites. While routers > >>will default to having a unique site-local zone id for each > >>interface (thus rendering SLs to link-local behavior) unless > >>explicitly configured to have multiple interfaces in the same site. > >> > >>This difference in behavior for hosts and routers leads to > >>some interesting issues. One big one is how the site-local > >>zone ids are setup and potentially changed when a host > >>becomes a router or vice versa. > >> > >>What are others' opinions on this issue? > >> > >>Brian > >> > >>-------------------------------------------------------------------- > >>IETF IPng Working Group Mailing List > >>IPng Home Page: http://playground.sun.com/ipng > >>FTP archive: ftp://playground.sun.com/pub/ipng > >>Direct all administrative requests to majordomo@sunroof.eng.sun.com > >>-------------------------------------------------------------------- > >> > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 30 19:17:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3HX29022611; Wed, 30 Oct 2002 19:17:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3HXKA022610; Wed, 30 Oct 2002 19:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3HU29022603 for ; Wed, 30 Oct 2002 19:17:30 -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 g9V3HcbB016507 for ; Wed, 30 Oct 2002 19:17:38 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06569 for ; Wed, 30 Oct 2002 19:17:33 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 19:17:29 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Oct 2002 19:17:29 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Oct 2002 19:17:30 -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: Default site-local behavior for routers Date: Wed, 30 Oct 2002 19:17:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKAiVuWIiDc5nfLT/q8mX97moz9owAAK9EQ From: "Brian Zill" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 31 Oct 2002 03:17:30.0423 (UTC) FILETIME=[0BF5CC70:01C2808C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V3HU29022604 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman writes: > >>>In any case, the site boundary should never be larger >>>than the IGP scope, so if we are going to talk about >>>defaults, rather than assuming every interface is in a >>>different site, why not assume every EGP/IGP boundary >>>identifies a different site? If we can get past that, >>>maybe we can start talking about area boundaries as a >>>reasonable default. > > This works pretty well to bound the problem for routing > protocols and routers. > > I'm not sure that it does much, though, to address the issues > that site-locals raise for transport protocols, applications, > DNS and management protocols. Am I missing something? Well, this is the ipv6 working group's mailing list after all. We've been admonished before for messing around in other group's layers. But for what it's worth: I'm not aware of any problems scoped addresses cause for transport protocols, the modifications I had to make to our TCP implementation were straight-forward and obvious. Most applications don't pass around addresses in the data stream, and I've already explained in other email how the few that do can handle the issue. Others have spoken up with DNS solutions. Plus it is not clear to me that we need a DNS solution. Even Keith says "DNS should not be a MUST. not all applications need to use it. Also, DNS is a separate service from IP. IP should not be thought to be dependent on DNS." Personally, I think site-locals are a big win even if I only ever look them up in a hosts file. Finally, I'm not aware of any problems site-locals cause for management protocols either. --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 Oct 30 19:30:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3Un29022888; Wed, 30 Oct 2002 19:30:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3UnWo022886; Wed, 30 Oct 2002 19:30:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3Ui29022877 for ; Wed, 30 Oct 2002 19:30:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V3UqMq019797 for ; Wed, 30 Oct 2002 19:30:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04277 for ; Wed, 30 Oct 2002 20:30:47 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V3Ug007576; Wed, 30 Oct 2002 22:30:42 -0500 (EST) Message-Id: <200210310330.g9V3Ug007576@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 18:21:58 PST.") Date: Wed, 30 Oct 2002 22:30:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>> 1. applications don't know where their scope ends. > >> > >> They don't need to. If they are communicating with > >> another entity via a site-local address, then that > >> entity is by definition within scope. > > > > that doesn't mean that the entity that will end up > > using the address is within scope. > > If the entity in question wants to pass the address on, it needs to > follow the same rule. This keeps scoped addresses contained within the > scope where they are valid. yes, but it is too narrow a constraint - it doesn't allow referrals between hosts that share a scope to pass through an intermediary that does not share that scope. > > where do you get the idea that all referrals are > > one hop? > > I didn't say they were, and I thought most people would easily figure > out the point I made above. "most people" don't write distributed applications (though they probably do use them without being aware of it) > >> Therefore they can legitimately pass a site-local > >> address in the data stream to that entity. Otherwise, > >> they can't. Very simple and straight-forward. > > > >it's simple, straight-forward -- and incorrect. > > On the contrary, I've shown where it is correct. You have failed to > justify your accusation. I've justified it on multiple occasions, you just don't want to listen - either that or you think that communications paths within an application should be organized into a hierarchy with all intermediations between nodes in the same scope being done by an intermediary that shares tha scope. It won't fly. > >>> 2. expecting applications to know about network > >>> topology drastically increases their complexity > >>> without any recognizable benefits. > >> > >> As noted above, the applications don't need to know=20 > >> anything about the network topology, they only need > >> to know what kind of addresses they are using. > >=20 > >False. there's no way that a referrer can know what > >scopes the party to which the addresses are being > >referred has access to. the best the referrer can do > >is refer all available addresses. even then, without > >global scope IDs we don't have a way for the party=20 > >using those referrals to know which addresses are valid > >in the scopes to which it has access. > > No, as I've clearly shown above, an application can easily ensure that > it only refers addresses which are meaningful to referee. and as I've clearly shown above, this prevents referrals from working in cases where the nodes should be able to communicate. > But this can only > work if we have site-local addresses. If we force people to use random > global address space as non-routable, then apps will have no choice but > to blindly pass them around in the data stream (as I pointed out in my > previous mail). Which is *exactly* what they should be doing - first because it's not the app's job to know about network topology, second because it's not the app's job to define its own address space (so that it can make referrals work) or to route messages through the network, third because trying to adapt apps to keep up with scopes - even in the simplistic way that you suggest - is not only insufficient, it's a non-starter. > > >> If, however, random global address which happened > >> not to be globally routable (due to firewalls/filters) > >> were used, the app couldn't determine this, and could > >> end up blindly passing these non-routable=20 > >> addresses around in the data stream. > >=20 > >yes, > > Glad to see we agree on something :-) > > >but since the addresses are global the party that is=20 > >*using* the addresses has at least some chance of knowing=20 > >whether it has access to them. > > As I've shown above, proper use of site-locals solves this problem. no, you've just picked a corner case where your "solution" happens to work. the reality is that such apps will need to forward SLs around just in case there aren't any globals, or the globals don't work. and they'll have to implement their own naming systems because the addresses are ambiguous, and they'll have to verify each peer's identity because using an SL address might cause it to reach a different host than intended. > And here I thought you were against apps needing to know about network > topology? Most end-hosts have a default route to their first-hop > router, that's it. They don't know anything more about what prefixes > are reachable. Non-routable globals aren't the answer. Again, the > solution I've outlined is simple, practical, and works today. no it doesn't. why don't you actually try making this work in real distributed apps before making such ridiculous claims? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 19:35:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3ZP29022966; Wed, 30 Oct 2002 19:35:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3ZP88022965; Wed, 30 Oct 2002 19:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3ZL29022958 for ; Wed, 30 Oct 2002 19:35:21 -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 g9V3ZTMq020760 for ; Wed, 30 Oct 2002 19:35:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28565 for ; Wed, 30 Oct 2002 20:35:23 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V3Y6007591; Wed, 30 Oct 2002 22:34:06 -0500 (EST) Message-Id: <200210310334.g9V3Y6007591@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 13:27:32 +1100.") <200210310227.g9V2RWBM068124@drugs.dv.isc.org> Date: Wed, 30 Oct 2002 22:34:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm talking about 1 name with multiple addresses being > > returned in multiple scopes. I'm taking about having > > getaddrinfo() then filter out the inappropriate addresses > > using local knowledge and setting sin6_scope_id. > > This deals with 99.9% of address lookup. > > > > No, Mark, it doesn't, because the party that calls getaddrinfo > > isn't necessarily the same as the party (and doesn't share the same > > scopes as the party) that uses the addressees. > > List the number of application thay just lookup a address > then connect. > > Now list the number of applications that lookup a address > for a third party. > > My bet is that the result will be over 1000 to 1. a. the # of applications is not a good indicator of the effect on the internet's utility b. there are tens of thousands of apps that most of us have never heard of, that are vital for some purpose or another. the value of the internet is not just in being able to support the apps that everyone has heard of, it's in its flexibility to support a wide variety of communications needs > Also if you read the mail I admitted that there was a class > of applictation where getaddrinfo() is not enough. That > those applications would need a different API to look up > the addresses (or call the DNS directly). > > However that class of application could still determine > approriate remote SL to use by matching against the scope name > in the SA6 record and returning the address along with the > scope name. yes, but that's still trying to teach a pig to sing. giving the pig sheet music might help, but not much. > > there are numerous good reasons that many apps do NOT do a DNS lookup > > each time they want to contact another host. > > Which is irrelevent as to whether a address is in the DNS or > not. it's just one reason why putting SLs in the DNS won't solve the problems associated with SLs. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 19:38:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3cU29023029; Wed, 30 Oct 2002 19:38:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3cTVH023028; Wed, 30 Oct 2002 19:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3cP29023021 for ; Wed, 30 Oct 2002 19:38: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 g9V3cXbB020388 for ; Wed, 30 Oct 2002 19:38:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27103 for ; Wed, 30 Oct 2002 20:38:28 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V3b6007606; Wed, 30 Oct 2002 22:37:06 -0500 (EST) Message-Id: <200210310337.g9V3b6007606@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , alh-ietf@tndh.net, "'Bound, Jim'" , "'Tim Hartrick'" , ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 13:46:17 +1100.") <200210310246.g9V2kHBM068228@drugs.dv.isc.org> Date: Wed, 30 Oct 2002 22:37:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > well, I'd probably agree with that, because it provides an easy way to > > attack an isolated network that was legitimately using SLs. still, > > a network that is using globals shouldn't be using SLs. > > Well don't configure *your* network to do this. Stop trying > to preventing those that do from doing so. and *you* stop trying to impair the Internet in such a way that the only applications it can support are client-server or those organized into a strict hierarchy that reflects physical topology, and stop trying to saddle such applications with useless complexity and performance impairment. and you accuse *me* of tunnel vision. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 19:46:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3kN29023233; Wed, 30 Oct 2002 19:46:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3kNbX023232; Wed, 30 Oct 2002 19:46:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3kJ29023225 for ; Wed, 30 Oct 2002 19:46:20 -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 g9V3kSbB021852 for ; Wed, 30 Oct 2002 19:46:28 -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 TAA04085 for ; Wed, 30 Oct 2002 19:46:22 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 19:46:22 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3E2@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAh90QLmCF4GaGSCi9Xe3kLAZLwgAB5AXg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V3kK29023226 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> A Monica strike is what Bill Clinton did a while ago: >> Make a lot of noise launching a bunch of cruise >> missiles at Saddam to try to get the people's >> attention away from the fact that he had a young >> lady under his desk. > Margaret Wasserman > Okay, so I am confused how it applies here. There's been a lot of noise here lately, without real reasons, and it has not produced much results either. 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 Oct 30 19:58:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3ws29023411; Wed, 30 Oct 2002 19:58:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V3wsV5023410; Wed, 30 Oct 2002 19:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V3wp29023403 for ; Wed, 30 Oct 2002 19:58:51 -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 g9V3wxbB023594 for ; Wed, 30 Oct 2002 19:58:59 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21476 for ; Wed, 30 Oct 2002 19:58:53 -0800 (PST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7D7AC18E2 for ; Wed, 30 Oct 2002 22:58:52 -0500 (EST) Date: Wed, 30 Oct 2002 22:58:52 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <2B81403386729140A3A899A8B39B046405E3E2@server2000> References: <2B81403386729140A3A899A8B39B046405E3E2@server2000> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021031035852.7D7AC18E2@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 30 Oct 2002 19:46:22 -0800, Michel Py wrote: > > There's been a lot of noise here lately, without real reasons, and it > has not produced much results either. You can call a concrete proposal to eliminate a chunk of unnecessary router complexity "noise" if you like, but I'll have to disagree. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 20:00:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V40B29023427; Wed, 30 Oct 2002 20:00:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V40AUk023426; Wed, 30 Oct 2002 20:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V40629023419 for ; Wed, 30 Oct 2002 20:00:06 -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 g9V40EbB023792 for ; Wed, 30 Oct 2002 20:00:14 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21404 for ; Wed, 30 Oct 2002 21:00:08 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V403007915; Wed, 30 Oct 2002 23:00:03 -0500 (EST) Message-Id: <200210310400.g9V403007915@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Dan Lanciani" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 18:14:54 PST.") <2B81403386729140A3A899A8B39B04640BD28B@server2000> Date: Wed, 30 Oct 2002 23:00:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Allow me to correct you: site-local are part of the IPv6 vision until > further notice, as they have been since longer than I can remember > without looking up references. site-locals are a beam that is blocking the IPv6 "vision". either they will get swept aside, or IPv6 will run into a wall. the fact that half-baked ideas have gotten this far without an understanding of their consequences for applications, and without adequate justification for their complexity, is NOT an excuse for perpetuating them. and if the best argument you can make in favor of SLs is to appeal to past mistakes, your case is very weak indeed. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 20:00:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V40w29023454; Wed, 30 Oct 2002 20:00:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V40wRj023453; Wed, 30 Oct 2002 20:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V40s29023443 for ; Wed, 30 Oct 2002 20:00: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 g9V412bB023897 for ; Wed, 30 Oct 2002 20:01:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21848 for ; Wed, 30 Oct 2002 21:00:56 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V40n007943; Wed, 30 Oct 2002 23:00:50 -0500 (EST) Message-Id: <200210310400.g9V40n007943@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Michel Py" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 21:47:05 EST.") <5.1.0.14.2.20021030214629.02e58c10@mail.windriver.com> Date: Wed, 30 Oct 2002 23:00:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Okay, so I am confused how it applies here. apparently the idea is that the president's sex life is really more worthy of attention than whether he's killing people. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 20:04:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V44B29023536; Wed, 30 Oct 2002 20:04:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V44BCI023535; Wed, 30 Oct 2002 20:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V44729023528 for ; Wed, 30 Oct 2002 20:04:07 -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 g9V44FbB024592 for ; Wed, 30 Oct 2002 20:04:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15737 for ; Wed, 30 Oct 2002 21:04:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V443008011; Wed, 30 Oct 2002 23:04:03 -0500 (EST) Message-Id: <200210310404.g9V443008011@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "31 Oct 2002 14:07:35 +1100.") <1036033655.7840.398.camel@dupy> Date: Wed, 30 Oct 2002 23:04:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Would "provider independent local addressing" be a better name for site > local addressing if Tony's model is the most commonly followed ? you don't want PI addresses to be constrained to be "local". you want to be able to privately route them between sites. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 20:05:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V45829023574; Wed, 30 Oct 2002 20:05:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V457Dp023573; Wed, 30 Oct 2002 20:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V45429023566 for ; Wed, 30 Oct 2002 20:05:04 -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 g9V45CMq025979 for ; Wed, 30 Oct 2002 20:05:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23925 for ; Wed, 30 Oct 2002 20:05:07 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 20:05:07 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3E3@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAa4L/wzOB4PBaQCauJgcrH/fXjgAJg2Qg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V45429023567 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > You have made a statement that the use of IPv6 > site-local addresses (as opposed to globally > unique addresses) will increase the security > of a private network. And, I still don't > understand the basis for that claim. Semantics: I would have said "globally routable" instead of "globally unique", as some mechanisms such as including the ASN in the upper bits of a site-local address could make it globally unique and not globally routable. That being said, the reasons the mechanism mentioned above has not convinced is because it was a disguised globally routable address anyway. > Could you please answer the following question > that I posted earlier? I have. Shall I expect a response, or is what Richard and I have posted enough to convince you that there are indeed some security benefits in using site-local address when designing a security perimeter in a private network? 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 Oct 30 20:16:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V4GL29023858; Wed, 30 Oct 2002 20:16:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V4GL1c023857; Wed, 30 Oct 2002 20:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V4GI29023850 for ; Wed, 30 Oct 2002 20:16: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 g9V4GQMq027778 for ; Wed, 30 Oct 2002 20:16:26 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28034 for ; Wed, 30 Oct 2002 21:16:20 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id CB6FB3B371; Thu, 31 Oct 2002 15:16:15 +1100 (EST) Subject: Re: Default site-local behavior for routers From: Mark Smith To: Keith Moore Cc: Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210310404.g9V443008011@astro.cs.utk.edu> References: <200210310404.g9V443008011@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 15:16:15 +1100 Message-Id: <1036037778.7840.403.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oops, sorry, I think I overloaded an already defined term. Maybe "enterprise local addressing" or something similar that doesn't imply a geographical size or location, and indicates the addressing uniqueness is only local to the organisation using it. On Thu, 2002-10-31 at 15:04, Keith Moore wrote: > > Would "provider independent local addressing" be a better name for site > > local addressing if Tony's model is the most commonly followed ? > > you don't want PI addresses to be constrained to be "local". you want > to be able to privately route them between sites. > > Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 20:36:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V4aU29024125; Wed, 30 Oct 2002 20:36:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V4aUOG024124; Wed, 30 Oct 2002 20:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V4aQ29024117 for ; Wed, 30 Oct 2002 20:36:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V4aYbB029609 for ; Wed, 30 Oct 2002 20:36:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26681 for ; Wed, 30 Oct 2002 21:36:28 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V4aM008509; Wed, 30 Oct 2002 23:36:22 -0500 (EST) Message-Id: <200210310436.g9V4aM008509@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "31 Oct 2002 15:16:15 +1100.") <1036037778.7840.403.camel@dupy> Date: Wed, 30 Oct 2002 23:36:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Oops, sorry, I think I overloaded an already defined term. > > Maybe "enterprise local addressing" or something similar that doesn't > imply a geographical size or location, and indicates the addressing > uniqueness is only local to the organisation using it. there's no need for such addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:08:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V58b29024304; Wed, 30 Oct 2002 21:08:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V58bV1024303; Wed, 30 Oct 2002 21:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V58X29024296 for ; Wed, 30 Oct 2002 21:08:33 -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 g9V58fMq005895 for ; Wed, 30 Oct 2002 21:08:41 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05700 for ; Wed, 30 Oct 2002 22:08:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V58P008713; Thu, 31 Oct 2002 00:08:25 -0500 (EST) Message-Id: <200210310508.g9V58P008713@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 20:05:07 PST.") <2B81403386729140A3A899A8B39B046405E3E3@server2000> Date: Thu, 31 Oct 2002 00:08:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Shall I expect a response, or is what Richard and I have posted > enough to convince you that there are indeed some security benefits in > using site-local address when designing a security perimeter in a > private network? I don't think you've made a convincing case for this. I generally agree that an SL address that somehow appears in a network remote from the site in which it was used is not likely to be able to make it back to that site via the network's normal routing mechanisms. Some sort of tunnel is likely to be necessary. On the other hand there are far more opportunities to filter an address that does have a global prefix (you're not limited to filtering them at the border of the "site"), or to detect the use of such addresses on networks where they are supposed to be filtered, or to log such addresses for traffic analysis. I also don't think you've made a convincing case that a single, non-permeable security perimeter is a very useful feature of an addressing architecture. I do think you've made a case for using SLs in isolated networks, or nearly isolated networks where the only interactions between those networks and other networks are via special-purpose applications. As I said earlier I don't have a problem with using SLs in that corner case. I do have a problem with promoting SLs as a security mechanism for use in general-purpose network where off-the-shelf apps are exposed to a mixture of SLs and globals. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:11:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5BC29024338; Wed, 30 Oct 2002 21:11:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5BCOU024337; Wed, 30 Oct 2002 21:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5B829024330 for ; Wed, 30 Oct 2002 21:11:09 -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 g9V5BGMq006341 for ; Wed, 30 Oct 2002 21:11:17 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09026 for ; Wed, 30 Oct 2002 22:11:10 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 4FA643B371; Thu, 31 Oct 2002 16:11:01 +1100 (EST) Subject: Re: Default site-local behavior for routers From: Mark Smith To: Keith Moore Cc: Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210310436.g9V4aM008509@astro.cs.utk.edu> References: <200210310436.g9V4aM008509@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 16:11:01 +1100 Message-Id: <1036041065.7840.422.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think there is in Australia ... Have a read of my previous emails. If I was to build a very simple enterprise network between 8 capital cities, with an single ethernet segment in each, and 7 wan links connecting them, if I follow the current site-local definition (geographical boundaries define site local boundaries), I think I'm going to need 8 multi-site routers, and will have a total of 15 different site-local addressing instances. Hmm, I think I'll just ignore the current site-local geographical definition, and number all my links out of the 2^56 bit subnet address space I have in a single site-local fec0::/10 address space. If nothing else, I don't want to pay the extra premium to a router vendor to get a multi-site feature set on all the routers in this network, just to follow a addressing name definition. On the other hand, that additional feature set cost is likely to be cheaper than the cost in explaining why every link in the network is called a "site" to my boss. It could cost me my job. On Thu, 2002-10-31 at 15:36, Keith Moore wrote: > > Oops, sorry, I think I overloaded an already defined term. > > > > Maybe "enterprise local addressing" or something similar that doesn't > > imply a geographical size or location, and indicates the addressing > > uniqueness is only local to the organisation using it. > > there's no need for such addresses. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:13:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5DR29024376; Wed, 30 Oct 2002 21:13:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5DRHN024375; Wed, 30 Oct 2002 21:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5DO29024368 for ; Wed, 30 Oct 2002 21:13: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 g9V5DWMq006664 for ; Wed, 30 Oct 2002 21:13:32 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09715 for ; Wed, 30 Oct 2002 22:13:26 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 00B7E319D; Thu, 31 Oct 2002 00:13:26 -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, 31 Oct 2002 00:13:21 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:13:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97EF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAbMY0GFx6P9AwQH6uYvGC5ZDEXQALzVIA From: "Bound, Jim" To: "Ole Troan" , "Jun-ichiro itojun Hagino" Cc: "Richard Draves" , X-OriginalArrivalTime: 31 Oct 2002 05:13:21.0705 (UTC) FILETIME=[3B3F4190:01C2809C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5DO29024369 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole, Question: So what would you suggest in wording that we can provide to state that this should be the case to prevent any notion of SLs being forwarded in our specs. Rather than just trust the good intentions of suppliers? That might be the BCP. But we cannot leave it as it is per this discussion. I would like to not have it again on the list. What is your suggestion? thanks /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com] > Sent: Wednesday, October 30, 2002 6:31 PM > To: Jun-ichiro itojun Hagino > Cc: Richard Draves; ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > >>> A router might (and probably should) be hard-coded not to > >>> forward link-local packets, as there is no reason to ever > >>> forward them. > >>> > >>> However, a router that might ever need have multiple > >>> interfaces in a single site can't be hard-coded not to > >>> forward site-locals. Whether or not they will be forwarded is > >>> the result of configuration. > >> > >>Actually, a router can forward link-locals between > interfaces on the > >>same link. In particular, a router can forward a packet with > >>link-local dest and/or source back out the interface from which it > >>arrived (and presumably generate a Redirect too). > >> > >>If you are implementing link-locals properly, it's really > very little > >>additional code to support site-locals. At least that's my > experience. > > > > could you comment on routing code? (RIPng, OSPFv3) i > still think > > it's way too tough to support multi-sited node. > > RIPng is relatively simple. link-state protocols require > congruent areas and sites. there are some open issues with > regards to multicast and PIM I believe. routing protocol > support is required in any case for VPNs. > > site-locals can be used without multi-site support, i.e > treated pretty much like globals. multi-sited-ness shouldn't > be recommended for other reasons than adding complexity to > routers, e.g DNS issues. > > /ot > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:20:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5KC29024476; Wed, 30 Oct 2002 21:20:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5KCHu024475; Wed, 30 Oct 2002 21:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5K929024466 for ; Wed, 30 Oct 2002 21:20: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 g9V5KHMq007943 for ; Wed, 30 Oct 2002 21:20:17 -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 VAA21490 for ; Wed, 30 Oct 2002 21:20:12 -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 831218CA; Thu, 31 Oct 2002 00:20: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); Thu, 31 Oct 2002 00:20:07 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:20:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B647@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAb/xUfL6HP+SXS4KST1f5ybQCPQALHjBQ From: "Bound, Jim" To: , "Tim Hartrick" , , X-OriginalArrivalTime: 31 Oct 2002 05:20:07.0571 (UTC) FILETIME=[2D297E30:01C2809D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5K929024469 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, What I want is a simple draft that says site-locals will not be forwarded out of the site? Brian Haberman et als work had that wordage but the other parts are far from consensus. What we could do is have Brian reduce to one draft working with Ole a statement that this will not happen. We need a bit more than trust me it won't happen. But in the implementation community you know this is not going to happen if the majority of nodes need global and site access they will just use global. Which is my recommendation in that case. I have not met an IPv6 adopter yet that wants them once they realize they are not for security. There is no reason for them if you can secure two nodes communicating, a firewall, in an MLS environment most mission critical folks want for security as you know and end-2-end apps. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, October 30, 2002 6:56 PM > To: Bound, Jim; 'Tim Hartrick'; ipng@sunroof.eng.sun.com; > richdr@microsoft.com > Subject: RE: Limiting the Use of Site-Local > > > Jim, > > The fundamental difference is the assumption about what is a > reasonable network topology. It is absolutely wrong to turn > off SL just because a global exists, because neighboring > nodes on a single wire may have local policy to be globally > visible or not. Insisting that SL gets turned off because one > node on the wire needs a global creates a very unreasonable > burden to manage access lists, particularly if that node > moves around between segments that would otherwise have no > global nodes. > > Again, I am sympathetic to the point that multi-party apps > should refuse to refer a SL if any of the members has a > global, but that is at best a BCP targeted at app developers. > > Tony > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Wednesday, October 30, 2002 3:17 PM > > To: alh-ietf@tndh.net; Tim Hartrick; > > ipng@sunroof.eng.sun.com; richdr@microsoft.com > > Subject: RE: Limiting the Use of Site-Local > > > > > > Tony and Tim, > > > > I agree with Tim about the flow. But I strongly support > > Margarets idea to limit them today to not be part of domain > > where global addresses exist as Margaret has clearly > > articulated. Support for that is not a minority and not > > rehash but putting some controls on an architectural part of > > IPv6 that is not understood, widely implemented, or deployed > > as product with express warranty that it can be used in > > production networks. > > > > So keep it in the architecture and lets put a control on it > > right now and move on. > > > > I am personally not going to participate any further I have > > nothing else to say. > > > > P.S. Tim I emphatically do not agree with your views on 1918 > > and I was here as you when it was developed. But I see no > > point in kicking that > > dead horse either. We simply do not agree. It is moot > > point though I > > do agree. > > > > P.S. Margaret if we can get folks to do this correct > > engineering change order I will help with the draft if you > > require that. But for now I am DELETING all this mail on > > killing SLs entirely it will not happen. Though they should > > die and all should use globals the next best thing is to put > > controls on this mess until we understand how to do it. > > > > /jim > > [In matters of style, swim with the currents....in matters of > > principle, stand like a rock. - Thomas Jefferson] > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Wednesday, October 30, 2002 4:01 PM > > > To: 'Tim Hartrick'; ipng@sunroof.eng.sun.com; richdr@microsoft.com > > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > Thank you! > > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of > Tim Hartrick > > > > Sent: Tuesday, October 29, 2002 4:41 PM > > > > To: ipng@sunroof.eng.sun.com; richdr@microsoft.com > > > > Subject: RE: Limiting the Use of Site-Local > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > I generally agree with all the points that Richard Draves > > has made. > > > > I am not as sanguine about the ease of implementation in > > the network > > > > stack but there is nothing in the details which is unimaginably > > > > difficult. We very much need to move on. By my count > this is the > > > > forth or fifth time this topic has been debated and > > redebated. Each > > > > time the result has been the same. If every decision > > taken by this > > > > working group can be opened repeatedly by a noisy minority then > > > > forward progress of any sort will not be possible. > Consensus does > > > > not require unanimity. No matter how noisy and persistent > > > > the minority happens to be, it is possible to move on. > > > > > > > > There are a couple of other points I would like to make. > > > > > > > > Some folks seem to be operating under a misconception about RFC > > > > 1918. RFC 1918 was a response to the rampant use of > > arbitrary IPv4 > > > > prefixes as private address space. The use of private > > address space > > > > was not a response to the publishing of RFC 1918. Network > > > > administrators will use "private" IPv6 address space whether we > > > > excise all mention of site-local addresses from the > > specifications > > > > or not. The network administrators that use private > > address space > > > > may be stupid, misinformed or have any number of socially > > > > unacceptable habits but they still run their networks and > > will run > > > > their networks the way they see fit. Removing > site-local addresses > > > > from the architecture or attempting to restrict their > use in a way > > > > that is equivalent to removing them is an exercise in futility > > > > absent better alternatives to site-local addresses. > > > > > > > > The burden on those that want to remove site-local > > addresses is to > > > > provide network administrators with an alternative which > > meets their > > > > needs but doesn't possess the negative aspects of site-local > > > > addresses that are being railed against. The requirements that > > > > network adminstrators would place on these addresses > > would probably > > > > be that there is no registration required and that the > > addresses are > > > > not globally routable. If such a proposal has been made > > and it has > > > > made it through last call of this working group, I must have > > > > missed it. Contrary to what has been said by some in the > > > > anti-site-local camp, the burden should be on them to > come up with > > > > alternatives to site-local addresses. Until those alternatives > > > > have been thoroughly vetted by this working group the previous > > > > consensus should hold. > > > > > > > > Counter to what one might believe from reading my > > comments above, I > > > > don't like the architectural mess that has occured as a > > consequence > > > > of the use private addresses in IPv4. The difference > > between me and > > > > the anti-site- local camp is that I don't anticipate > that network > > > > administrators will stop using private address (IPv6 or > > IPv4) unless > > > > they are provided with good reasons not to use them. That means > > > > solving renumbering, solving address shortage, artificial or > > > > otherwise, providing the an alternative "private" address > > > > scheme of the sort cited above and providing the great IPv6 > > > > applications which their customers want but that break in the > > > > presence of site-local addresses. If these things are done, > > > > it won't be necessary to add a bunch of MUST NOTs into the > > > > verbiage in various specifications. Site-local addresses and > > > > all the associated problems will fall into the dustbin of > > > > obsolescence. Absent these things, all the MUST NOTs in the > > > > world won't prevent the use of site-local addresses or some > > > > other form of IPv6 "private" address. > > > > > > > > Network administrators don't read RFCs for the MUST NOTs. > > They read > > > > them for the solutions they provide. If the MUST NOTs > get in the > > > > way of the solution then they get ignored. > > > > > > > > > > > > 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 > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 Oct 30 21:25:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5PY29024604; Wed, 30 Oct 2002 21:25:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5PYLe024603; Wed, 30 Oct 2002 21:25:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5PV29024596 for ; Wed, 30 Oct 2002 21:25:31 -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 g9V5PcbB006811 for ; Wed, 30 Oct 2002 21:25:38 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08037 for ; Wed, 30 Oct 2002 21:25:33 -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 A655F537A; Thu, 31 Oct 2002 00:25: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, 31 Oct 2002 00:25:28 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:25:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAcM0pMauGQslsRG+gZPdwktsoNwALIR1A From: "Bound, Jim" To: , "Rob Austein" Cc: X-OriginalArrivalTime: 31 Oct 2002 05:25:28.0461 (UTC) FILETIME=[EC6D6BD0:01C2809D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5PV29024597 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, > > Please think about this for a minute. It's bad enough for > > applications that are driven by a human who can type or click or > > whatever from a list of possible scopes, but what do you do for > > programs like MTAs? If you're longing for a return to the days of > > fee!fie%foe@fum email addresess (or even > SRA@XX.LCS.MIT.EDU.#Chaos), > > you're on the right road. > > No Rob. > > I'm talking about 1 name with multiple addresses being > returned in multiple scopes. I'm taking about having > getaddrinfo() then filter out the inappropriate addresses > using local knowledge and setting sin6_scope_id. > This deals with 99.9% of address lookup. We have not even agreed on what sin6_scope_ID is? It is also now deprecated for futher study in this wg in the base API except for link-local and in the IEEE. So how can you justify putting it in the DNS except as research? Did not we all learn from AAAAv6? Can you define what you mean by "local knowledge" How does DNS know that scope applies to the node that did the getaddrinfo if it don't know? Which all but a few implementations know today and I have many questions for those that say they do. 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 Oct 30 21:28:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5S829024654; Wed, 30 Oct 2002 21:28:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5S87i024653; Wed, 30 Oct 2002 21:28:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5S429024646 for ; Wed, 30 Oct 2002 21:28:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V5SCMq008886 for ; Wed, 30 Oct 2002 21:28:12 -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 WAA14621 for ; Wed, 30 Oct 2002 22:28:07 -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 C60DB76FF; Thu, 31 Oct 2002 00:28:06 -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, 31 Oct 2002 00:28:02 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:28:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F2@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAcZXB57lO0lADQMGwvGMcGTV6tgALIqiQ From: "Bound, Jim" To: "Mark Smith" , "Margaret Wasserman" Cc: "Richard Draves" , "Keith Moore" , X-OriginalArrivalTime: 31 Oct 2002 05:28:02.0600 (UTC) FILETIME=[484D2A80:01C2809E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5S429024647 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm guessing you mean an interface can only be in only one > site at a time, but not necessarily all members of the same site. But this is not an axiom we all have consensus on in any spec? As I said Brian Haberman had this but we did not bless it. And the AD's don't bless that spec yet either. This is what we need stated. /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 Oct 30 21:29:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5TX29024690; Wed, 30 Oct 2002 21:29:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5TXpI024689; Wed, 30 Oct 2002 21:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5TT29024682 for ; Wed, 30 Oct 2002 21:29:29 -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 g9V5TbMq009172 for ; Wed, 30 Oct 2002 21:29:37 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15137 for ; Wed, 30 Oct 2002 22:29:32 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9V5TO008795; Thu, 31 Oct 2002 00:29:24 -0500 (EST) Message-Id: <200210310529.g9V5TO008795@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "31 Oct 2002 16:11:01 +1100.") <1036041065.7840.422.camel@dupy> Date: Thu, 31 Oct 2002 00:29:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if multi-site routers really did cost more than single-site routers, that's even more reason to not use SLs - since the same effect could be achieved at less cost using globals and prefix-based filtering. however I'd be really surprised if SL filtering added to the cost of a router. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:30:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5Um29024770; Wed, 30 Oct 2002 21:30:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5UlsD024768; Wed, 30 Oct 2002 21:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5Ug29024737 for ; Wed, 30 Oct 2002 21:30:42 -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 g9V5UoMq009472 for ; Wed, 30 Oct 2002 21:30:50 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26152 for ; Wed, 30 Oct 2002 22:30:44 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B5BDA51F7; Thu, 31 Oct 2002 00:30:43 -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, 31 Oct 2002 00:30:39 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:30:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAdSM9Ei6rfGciTMee0wW0QHXhiAAKTz+w From: "Bound, Jim" To: "Rob Austein" , X-OriginalArrivalTime: 31 Oct 2002 05:30:39.0618 (UTC) FILETIME=[A5E43620:01C2809E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5Ug29024739 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 002 10:59:45 +1100, Mark Andrews wrote: > > > > I'm talking about 1 name with multiple addresses being > > returned in multiple scopes. I'm taking about having > > getaddrinfo() then filter out the inappropriate addresses > > using local knowledge and setting sin6_scope_id. > > Via this mapping table thingie, which I suppose we could > configure easily enough using DHCPv6. So what happens when > the mapping table isn't configured, is misconfigured, or > somebody passes a raw scoped IP address into some other scope? In a mission critical network an error like this could mean someone is dead for one thing. The above assumes DHCPv6 would have the knowledge of the network or we would need new options to negotiate SLs and topology in general. That will take awhile to parse IMO in the WG and here. /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 Oct 30 21:35:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5Zg29024935; Wed, 30 Oct 2002 21:35:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5ZgIp024934; Wed, 30 Oct 2002 21:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5Zd29024927 for ; Wed, 30 Oct 2002 21:35:39 -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 g9V5ZkbB008464 for ; Wed, 30 Oct 2002 21:35:47 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15925 for ; Wed, 30 Oct 2002 22:35:40 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2D1D35225; Thu, 31 Oct 2002 00:35:40 -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, 31 Oct 2002 00:35:36 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:35:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F4@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAemB07K8xtQzTRVCI5jUxY2DmAgAJJCjA From: "Bound, Jim" To: "Keith Moore" Cc: , "Tim Hartrick" , , X-OriginalArrivalTime: 31 Oct 2002 05:35:36.0000 (UTC) FILETIME=[568C8400:01C2809F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5Zd29024928 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I talk people out of using them at least once every two weeks as I get a lot of mail on this. I did have one case where they made sense. A factory floor where they have no connection to the outside for robotics. The reason was they did not want to mess in the architecture of this part of the network with asking for IPv6 addresses. In that case they can use IPv6 without an ISP or paying for the address and getting one. Or managing this space. But most people want both global and site and when I am done they just want global. 1918 was not digested in a pure form (if one existed) but in a brain dead form and gave many users the wrong impression. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, October 30, 2002 8:11 PM > To: Bound, Jim > Cc: alh-ietf@tndh.net; Tim Hartrick; > ipng@sunroof.eng.sun.com; richdr@microsoft.com > Subject: Re: Limiting the Use of Site-Local > > > > I would also ask all those who want to kill SLs turn your > support to > > Margaret to put the controls on. > > Yes, this is the position I support. > > Even I do not expect to kill SLs in the sense that we would > reallocate those addresses for other purposes, forbid using > them under all > conditions, expect routers to always filter them or hosts to always > ignore them, etc. I don't like pulling the rug out from under > people who have built designs around them, even if I think > their designs are shortsighted and/or naive. > > I do however think we need to discourage use of SLs except in > isolated networks. > > I also think we need to make it clear that in general applications > aren't expected to work in the presence of a mixture of scoped and > global addresses. Applications should treat SLs exactly like > global addresses. > > Finally I think we need to discourage the idea that SLs are a > security mechanism, because SL filters are at best only > marginally better than other kinds of address filters (and > I'm being charitable there). > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:38:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5cE29025022; Wed, 30 Oct 2002 21:38:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5cEHj025021; Wed, 30 Oct 2002 21:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5cA29025011 for ; Wed, 30 Oct 2002 21:38:10 -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 g9V5cIMq010599 for ; Wed, 30 Oct 2002 21:38:18 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16664 for ; Wed, 30 Oct 2002 22:38:12 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 232535F6F; Thu, 31 Oct 2002 00:38:12 -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, 31 Oct 2002 00:38:07 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:38:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F5@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAetOwoB5UurtsRHW3YjjnoVmvcQAJIpXw From: "Bound, Jim" To: "Keith Moore" , Cc: X-OriginalArrivalTime: 31 Oct 2002 05:38:07.0920 (UTC) FILETIME=[B119AB00:01C2809F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5cA29025012 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree and it was a personal attack and you should get an apology as all your arguments have been technical challenges. The remark was out of line. Keith - the rule I use on that one is I confront them directly in person at the IETF when they do that about their behavior. And I find more are much more bold in email than in person. I am sure you will handle it much better than I would in person :---) /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, October 30, 2002 8:12 PM > To: alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > That summarizes it well. > > and it appears to me that you are trying to attack me > personally rather than actually make credible arguments in > favor of using SL. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 30 21:41:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5fs29025123; Wed, 30 Oct 2002 21:41:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5fslt025122; Wed, 30 Oct 2002 21:41:54 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5fp29025115 for ; Wed, 30 Oct 2002 21:41:51 -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 g9V5fxMq011088 for ; Wed, 30 Oct 2002 21:41:59 -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 VAA13984 for ; Wed, 30 Oct 2002 21:41:53 -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 7F0463210; Thu, 31 Oct 2002 00:41:53 -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, 31 Oct 2002 00:41:49 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:41:48 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAgkFmuf3RT/IFTUeMlXW6HPzdTQAHYQhA From: "Bound, Jim" To: "Brian Haberman" , "Jun-ichiro itojun Hagino" Cc: "Richard Draves" , X-OriginalArrivalTime: 31 Oct 2002 05:41:49.0277 (UTC) FILETIME=[350A10D0:01C280A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5fp29025116 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think Brian should do this on the agenda as a necessity. Lets here from someone who can tell us how they implemented it and also is a routing engineer and obviously can disclose to us details which I know well we cannot always do here in public. This should be a priority agenda item not to kill SLs but to learn from this implementors experience. Now I am sure my colleagues on either side do not disagree that this is important. I also think Mark speaking on his DNS methods would be of value too. As the DNS part is quite important. In fact lets have a technical meeting on issues and not status updates of drafts. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: Wednesday, October 30, 2002 9:02 PM > To: Jun-ichiro itojun Hagino > Cc: Richard Draves; ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > > Jun-ichiro itojun Hagino wrote: > > > > could you comment on routing code? (RIPng, OSPFv3) i > still think > > it's way too tough to support multi-sited node. > > Not that the chairs have finalized the agenda, but I am > planning on presenting what it took me to get a site-border > router coded and running. If you want to request a certain > level of detail, let me know. > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:44:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5ib29025191; Wed, 30 Oct 2002 21:44:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5iapY025190; Wed, 30 Oct 2002 21:44:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5iX29025183 for ; Wed, 30 Oct 2002 21:44:33 -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 g9V5ifbB009697 for ; Wed, 30 Oct 2002 21:44:41 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20552 for ; Wed, 30 Oct 2002 22:44:35 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 61BDA52CC; Thu, 31 Oct 2002 00:44: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); Thu, 31 Oct 2002 00:44:31 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:44:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhOoCZB14DwGdSGy+WhY/SyczaAAG3fCg From: "Bound, Jim" To: "Brian Haberman" , "Ole Troan" Cc: "Jun-ichiro itojun Hagino" , "Richard Draves" , X-OriginalArrivalTime: 31 Oct 2002 05:44:31.0383 (UTC) FILETIME=[95A97A70:01C280A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5iY29025184 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I would be also interested in the conditionals in this which is best case 3 machine instructions too. And what the conditionals did to the complexity of the code and future maintance. Of course I am not clear implementation details interest many these days in our decision process. Its like we infinite time and infinite resources to do IPv6. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Brian Haberman [mailto:bkhabs@nc.rr.com] > Sent: Wednesday, October 30, 2002 9:08 PM > To: Ole Troan > Cc: Jun-ichiro itojun Hagino; Richard Draves; ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > > Ole Troan wrote: > >>>>A router might (and probably should) be hard-coded not to > >>>>forward link-local packets, as there is no reason to ever > >>>>forward them. > >>>> > >>>>However, a router that might ever need have multiple > >>>>interfaces in a single site can't be hard-coded not to > >>>>forward site-locals. Whether or not they will be forwarded is > >>>>the result of configuration. > >>> > >>>Actually, a router can forward link-locals between > interfaces on the > >>>same link. In particular, a router can forward a packet with > >>>link-local dest and/or source back out the interface from which it > >>>arrived (and presumably generate a Redirect too). > >>> > >>>If you are implementing link-locals properly, it's really > very little > >>>additional code to support site-locals. At least that's my > >>>experience. > >> > >> could you comment on routing code? (RIPng, OSPFv3) i > still think > >> it's way too tough to support multi-sited node. > > > > > > RIPng is relatively simple. link-state protocols require congruent > > areas and sites. there are some open issues with regards to > multicast > > and PIM I believe. routing protocol support is required in any case > > for VPNs. > > The actual routing protocol changes in RIPng is dependent on > how you structure your RIBs. I hacked RIPng to make an SBR > using a monolithic RIB with an additional index (the zone > id). It was an additional 800-900 lines of code to deal with > figuring out which RIB entries needed to be advertised on > each interface. > > Then there are the changes to configure and maintain the zone IDs. > > The biggest hit is actually in the forwarding. Each packet > gets at least one additional table lookup (for the incoming > zone id). Then there are the checks to ensure that the > source address is valid (e.g. a site-local SA and global DA > trying to cross a site border). > > The extra cost? Performance drops around 25-30% for a SBR > between 3 sites. Of course, this was all software based, but > even a hardware-based solution will take the extra lookup hits. > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 21:52:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5qe29025380; Wed, 30 Oct 2002 21:52:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5qe6G025379; Wed, 30 Oct 2002 21:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5qa29025372 for ; Wed, 30 Oct 2002 21:52:36 -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 g9V5qibB010756 for ; Wed, 30 Oct 2002 21:52:44 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA21614 for ; Wed, 30 Oct 2002 22:52:38 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 94965454E; Thu, 31 Oct 2002 00:52:37 -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, 31 Oct 2002 00:52:33 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:52:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B648@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhUR1oc8bUNgQQ7mwxHMY+SuU5QAACJKAAAbn5oA= From: "Bound, Jim" To: "Michel Py" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 31 Oct 2002 05:52:33.0362 (UTC) FILETIME=[B4F1A320:01C280A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5qb29025373 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, > > What is a Monica strike? > > A Monica strike is what Bill Clinton did a while ago: Make a > lot of noise launching a bunch of cruise missiles at Saddam > to try to get the people's attention away from the fact that > he had a young lady under his desk. If your at this upcoming IETF I would love to speak to you about this statement in person OK. So lets go offline and figure out when we can meet. How about the Hard Rock Café one night. I would love to delve deeper into your knowledge of the inner workings of one of our Presidents. Of course I will share my opinion of your statement but only to you and in person just btw us ok. Also I was not a supporter of this President but he was the President. Mind if I bring a couple of Gulf War Veterans I can probably locate in Atlanta? But we digress. And apologize to the list but had to respond. I will stop here. Look forward to seeing ya guy, /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 Oct 30 21:57:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5v529025449; Wed, 30 Oct 2002 21:57:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V5v5I2025448; Wed, 30 Oct 2002 21:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V5v129025441 for ; Wed, 30 Oct 2002 21:57:01 -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 g9V5vAMq013331 for ; Wed, 30 Oct 2002 21:57:10 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05744 for ; Wed, 30 Oct 2002 22:57:04 -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 F100974A6; Thu, 31 Oct 2002 00:57:03 -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, 31 Oct 2002 00:56:59 -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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 00:56:58 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE97FD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAiBTkXHyJ+2WrThalslMUmQz3ggAGihJQ From: "Bound, Jim" To: "Margaret Wasserman" , "Michel Py" Cc: X-OriginalArrivalTime: 31 Oct 2002 05:56:59.0493 (UTC) FILETIME=[53920150:01C280A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V5v229025442 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Silly me too. I thought valuing differences was part of our jaundra in the IETF and I am on the right side of things too. Oh well I learn everyday. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Wednesday, October 30, 2002 9:47 PM > To: Michel Py > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Okay, so I am confused how it applies here. > > I'd be very surprised to learn that I have a young lady under > my desk... > > Margaret > > > At 09:32 PM 10/30/02, Michel Py wrote: > > > What is a Monica strike? > > > >A Monica strike is what Bill Clinton did a while ago: Make a lot of > >noise launching a bunch of cruise missiles at Saddam to try > to get the > >people's attention away from the fact that he had a young lady under > >his desk. > > > >Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 22:15:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6F429025756; Wed, 30 Oct 2002 22:15:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V6F4Hf025755; Wed, 30 Oct 2002 22:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6F129025748 for ; Wed, 30 Oct 2002 22:15:01 -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 g9V6F9bB013583 for ; Wed, 30 Oct 2002 22:15:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01141 for ; Wed, 30 Oct 2002 23:15:03 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 22:15:08 -0800 Reply-To: From: "Tony Hain" To: Cc: Subject: RE: Limiting the Use of Site-Local Date: Wed, 30 Oct 2002 22:14:44 -0800 Message-ID: <000c01c280a4$ce648040$237ba8c0@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.3416 In-Reply-To: <200210310111.g9V1Bl007160@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9V6F129025749 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, I am not trying to attack, to the contrary I think I have simply been focused on defending a discussion settled so long ago that most of the interested parties have assumed it is done and they don't need to stay engaged. The only personal comment I am aware of was pointing out that you were asking for people to state why SL was necessary, but every time someone did you dismissed it out of hand because it didn't fit your policy of how a network should be run. That was not intended as a personal attack, so much as a wake up call to what was going on. You have a valid argument about making developers of multi-party apps aware that scope boundaries represent a new adventure that is not well defined yet. That does not automatically translate into the condition that all uses of SL are invalid (particularly 2 party ones). So instead of trying to blanket ban or restrict use of SL, state where the known pitfalls are, and let's move on. Tony > -----Original Message----- > From: moore@cs.utk.edu [mailto:moore@cs.utk.edu] > Sent: Wednesday, October 30, 2002 5:12 PM > To: alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > That summarizes it well. > > and it appears to me that you are trying to attack me > personally rather than actually make credible arguments in > favor of using SL. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 30 22:23:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6Nq29025902; Wed, 30 Oct 2002 22:23:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V6NqEp025901; Wed, 30 Oct 2002 22:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6Nm29025891 for ; Wed, 30 Oct 2002 22:23:48 -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 g9V6NubB014894 for ; Wed, 30 Oct 2002 22:23:56 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04791 for ; Wed, 30 Oct 2002 23:23:50 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 22:23:56 -0800 Reply-To: From: "Tony Hain" To: , "'Mark Smith'" Cc: "'Brian Haberman'" , Subject: RE: Default site-local behavior for routers Date: Wed, 30 Oct 2002 22:23:31 -0800 Message-ID: <000d01c280a6$0928a3e0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200210310436.g9V4aM008509@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > there's no need for such addresses. Enough managers of real networks created them, and still demand them that despite your claim that there is no need, there is a requirement that we provide something. 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 Wed Oct 30 22:48:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6ma29026270; Wed, 30 Oct 2002 22:48:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V6maMK026269; Wed, 30 Oct 2002 22:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V6mX29026262 for ; Wed, 30 Oct 2002 22:48:33 -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 g9V6mfbB018446 for ; Wed, 30 Oct 2002 22:48:41 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13177 for ; Wed, 30 Oct 2002 23:48:35 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id A23A63B371; Thu, 31 Oct 2002 17:48:32 +1100 (EST) Subject: Re: Default site-local behavior for routers From: Mark Smith To: Keith Moore Cc: Brian Haberman , alh-ietf@tndh.net, ipng@sunroof.eng.sun.com In-Reply-To: <200210310529.g9V5TO008795@astro.cs.utk.edu> References: <200210310529.g9V5TO008795@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 Oct 2002 17:48:32 +1100 Message-Id: <1036046913.11151.434.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-10-31 at 16:29, Keith Moore wrote: > > however I'd be really surprised if SL filtering added to the > cost of a router. > You're probably right. On the other hand, as per Ole Troan's earlier email (which I agree with), I don't think all router implementations should be required to support multi-sites. As soon as a feature is optional, it can be charged more for, and in my example, following the site-local philosophy, I would have to pay for it. BTW, I'm not sure if you miss-phrased, but we are talking about full multi-site forwarding support (ie zones etc), not just SL filtering. Mark. > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 00:03:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V83K29026637; Thu, 31 Oct 2002 00:03:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V83Je7026636; Thu, 31 Oct 2002 00:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V83G29026629 for ; Thu, 31 Oct 2002 00:03:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9V83LbB028719 for ; Thu, 31 Oct 2002 00:03:21 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27912 for ; Thu, 31 Oct 2002 00:03:15 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V80oc19843; Thu, 31 Oct 2002 10:00:50 +0200 Date: Thu, 31 Oct 2002 10:00:50 +0200 (EET) From: Pekka Savola To: Keith Moore cc: "Bound, Jim" , , Tim Hartrick , , Subject: Re: Limiting the Use of Site-Local In-Reply-To: <200210310111.g9V1B0007145@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 30 Oct 2002, Keith Moore wrote: > > I would also ask all those who want to kill SLs turn your support to > > Margaret to put the controls on. > > Yes, this is the position I support. As is mine. [...] > Finally I think we need to discourage the idea that SLs are a security > mechanism, because SL filters are at best only marginally better than > other kinds of address filters (and I'm being charitable there). And I'm being uncharitable: they give a false sense of security. Sure, you can make them work securely, but that's a lot of work. A bit like "privacy addresses" today. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 01:07:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V97r29026899; Thu, 31 Oct 2002 01:07:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9V97rC4026898; Thu, 31 Oct 2002 01:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9V97n29026891 for ; Thu, 31 Oct 2002 01:07:49 -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 g9V97wMq014631 for ; Thu, 31 Oct 2002 01:07:58 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13090 for ; Thu, 31 Oct 2002 02:07:48 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V97ip20373; Thu, 31 Oct 2002 11:07:44 +0200 Date: Thu, 31 Oct 2002 11:07:43 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C4D@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 31 Oct 2002, Hesham Soliman (EAB) wrote: > > > => Are you saying that site-local traffic would start > > > leaking outside the site and routed globally? > > > As in transient ISPs will just forward it? > > > > Of course the ISP's will forward them -- they (probably) > > haven't been > > configured to be part of any sites > > => Forward them where?? I can't imagine BGP not filtering > SLs coming from the downstream customers. Regardless > of what the spec says. BGP is not the point. Consider e.g.: [attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] Now the attacker can send packets with a fec0::/10 source address to the customer -- no one will block them unless they're explicitly configured as site borders -- before the customer itself. And if the customer does not block them, we're in for very serious trouble. That seemed to be what everyone except me read the ADDRARCH paragraph to imply. I thought attackers first-hop router (or at the latest, attackers edge router) should block these packets automatically. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 02:02:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VA2H29027100; Thu, 31 Oct 2002 02:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VA2HRb027099; Thu, 31 Oct 2002 02:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VA2E29027092 for ; Thu, 31 Oct 2002 02:02: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 g9VA2NbB015992 for ; Thu, 31 Oct 2002 02:02:24 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04268 for ; Thu, 31 Oct 2002 03:02:18 -0700 (MST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0EE9418E2 for ; Thu, 31 Oct 2002 05:02:17 -0500 (EST) Date: Thu, 31 Oct 2002 05:02:10 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: <000c01c280a4$ce648040$237ba8c0@eagleswings> References: <200210310111.g9V1Bl007160@astro.cs.utk.edu> <000c01c280a4$ce648040$237ba8c0@eagleswings> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021031100217.0EE9418E2@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 30 Oct 2002 22:14:44 -0800, Tony Hain wrote: > > ...I think I have simply been focused on defending a discussion > settled so long ago that most of the interested parties have assumed > it is done and they don't need to stay engaged. Since a check of the mailing list archive shows that the bulk of the traffic on site-local addresses over the years has come from people who quite obviously are still here (a tribute to their stamina, if not necessarily their good sense :), I'm curious about who these many interested but disengaged parties might be. I would also respectfully suggest that comments like: At Wed, 30 Oct 2002 14:57:29 -0800, Tony Hain wrote: > > Please don't interpret the ranting of a few as representing anything > close to consensus of a very large WG. are inappropriate, and say more about how much attention you're paying to the feedback we're getting from implementors than they do about whomever you were trying to insult in that message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 03:15:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VBFo29027601; Thu, 31 Oct 2002 03:15:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VBFodM027598; Thu, 31 Oct 2002 03:15:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VBFh29027591 for ; Thu, 31 Oct 2002 03:15:43 -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 g9VBFpbB025594 for ; Thu, 31 Oct 2002 03:15:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23567 for ; Thu, 31 Oct 2002 04:15:40 -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 GAA12830; Thu, 31 Oct 2002 06:13:16 -0500 (EST) Message-Id: <200210311113.GAA12830@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Date: Thu, 31 Oct 2002 06:13:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Plug and Play IPsec for IPv6 applications Author(s) : T. Kobayakawa, S. Miyakawa Filename : draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Pages : 5 Date : 2002-10-30 This document describes requirements about how IPsec is supplemented for IPv6 Plug and Play applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-30155419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30155419.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 Oct 31 05:10:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDAk29027852; Thu, 31 Oct 2002 05:10:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDAkdN027851; Thu, 31 Oct 2002 05:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDAg29027844 for ; Thu, 31 Oct 2002 05:10:42 -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 g9VDAoMq015842 for ; Thu, 31 Oct 2002 05:10:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21828 for ; Thu, 31 Oct 2002 06:10:44 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VDAf011107; Thu, 31 Oct 2002 08:10:42 -0500 (EST) Message-Id: <200210311310.g9VDAf011107@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Wed, 30 Oct 2002 22:14:44 PST.") <000c01c280a4$ce648040$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 08:10:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am not trying to attack, to the contrary I think I have simply been > focused on defending a discussion settled so long ago that most of the > interested parties have assumed it is done and they don't need to stay > engaged. I guess I disagree that the most interested parties - the developers of applications - were ever in the loop. This is IMHO IETF's biggest problem - working groups narrowly focused on specific problems routinely create large difficulties for interests that aren't involved in the working group. Zeroconf is another good example - by imposing LL addresses on IPv4 it is creating many of the same problems for v4 apps that SLs cause for v6 apps. (actually a couple of additional ones - at least v6 SLs are stable) > The only personal comment I am aware of was pointing out that > you were asking for people to state why SL was necessary, but every time > someone did you dismissed it out of hand because it didn't fit your > policy of how a network should be run. Well first I have this bizarre idea that networks exist to support a variety of applications - granted that this doesn't apply to _all_ networks, but I think it applies to most of them. Second I have this bizarre idea that if you want to impair operation of networks and of applications in the name of security, you should actually get a considerable security benefit from that impairment - and I don't think that has been demonstrated. > You have a valid argument about making developers of multi-party apps > aware that scope boundaries represent a new adventure that is not well > defined yet. That does not automatically translate into the condition > that all uses of SL are invalid (particularly 2 party ones). So instead > of trying to blanket ban or restrict use of SL, state where the known > pitfalls are, and let's move on. I think it makes far more sense to restrict or discourage use of SLs by networks than to restrict use of SLs by certain kinds of applications. I can't see any harm in doing the former, and doing the latter impairs the ability to run off-the-shelf multi-party apps anywhwere in the network. In effect it drastcially limits the market and the deployability of multi-party apps. In theory NATs wouldn't cause problems if they were only deployed on networks where they were known to not interfere with the apps that were running on those networks. In practice people have expected to run a variety of apps on NATted networks anyway, and no amount of complexity has produced a general-purpose solution to that problem. We need to restrict use of SL so that IPv6 doesn't end up causing most of the same problems for apps that NATs in IPv4 do. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 05:12:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDCV29027892; Thu, 31 Oct 2002 05:12:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDCVru027891; Thu, 31 Oct 2002 05:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDCR29027884 for ; Thu, 31 Oct 2002 05:12:27 -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 g9VDCZbB010342 for ; Thu, 31 Oct 2002 05:12:35 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12213 for ; Thu, 31 Oct 2002 06:12:30 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VDCN011123; Thu, 31 Oct 2002 08:12:23 -0500 (EST) Message-Id: <200210311312.g9VDCN011123@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Mark Smith'" , "'Brian Haberman'" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Wed, 30 Oct 2002 22:23:31 PST.") <000d01c280a6$0928a3e0$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 08:12:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Enough managers of real networks created them, and still demand them > that despite your claim that there is no need, there is a requirement > that we provide something. that's like saying that we have to do _something_ about bin Laden, so we might as well bomb a few thousand people who have nothing to do with him. yes, that kind of logic is commonly used. that doesn't make it right. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 05:17:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDHj29027959; Thu, 31 Oct 2002 05:17:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDHjN5027958; Thu, 31 Oct 2002 05:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDHg29027951 for ; Thu, 31 Oct 2002 05:17:42 -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 g9VDHobB011262 for ; Thu, 31 Oct 2002 05:17:50 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26098 for ; Thu, 31 Oct 2002 05:17:45 -0800 (PST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VDHNiZ016439; Thu, 31 Oct 2002 08:17:23 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 08:17:20 -0500 Message-ID: <3DC12E58.4020001@nc.rr.com> Date: Thu, 31 Oct 2002 08:21:28 -0500 From: Brian Haberman Organization: No Organization Here 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: Mark Smith CC: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <200210310529.g9V5TO008795@astro.cs.utk.edu> <1036046913.11151.434.camel@dupy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark Smith wrote: > On Thu, 2002-10-31 at 16:29, Keith Moore wrote: > >>however I'd be really surprised if SL filtering added to the >>cost of a router. >> > > > You're probably right. > > On the other hand, as per Ole Troan's earlier email (which I agree > with), I don't think all router implementations should be required to > support multi-sites. I think Ole's comments apply to specialized routers. If you are marketing a general purpose router, you almost have to put in support since you don't know how or where they will be deployed. > > As soon as a feature is optional, it can be charged more for, and in my > example, following the site-local philosophy, I would have to pay for > it. That depends based on my comment above. > > BTW, I'm not sure if you miss-phrased, but we are talking about full > multi-site forwarding support (ie zones etc), not just SL filtering. I break the problem down into two parts, pieces that already exist and pieces that really don't. Some of the forwarding rules for site-locals look alot like the ingress filtering that is done today to address spoofing. So, the machinery exists for that. As Ole pointed out in another message, there is some checking that is done for LL that can be re-used for SLs. The difference though is that the LL check doesn't require retrieving an index in order to check. What doesn't really exist is the filtering of prefixes being put into route exchange messages based on an arbitrary index (zone id). The other big issue is how the routing table(s) are built and managed. That can be a big hit on memory/storage space. 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 Oct 31 05:18:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDIR29027986; Thu, 31 Oct 2002 05:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDIRbN027985; Thu, 31 Oct 2002 05:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDIN29027975 for ; Thu, 31 Oct 2002 05:18:23 -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 g9VDIVMq017002 for ; Thu, 31 Oct 2002 05:18:32 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15736 for ; Thu, 31 Oct 2002 06:18:26 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VDIKQ1027649; Thu, 31 Oct 2002 14:18:20 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 14:17:01 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C4E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" Cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 14:16:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Forward them where?? I can't imagine BGP not filtering > > SLs coming from the downstream customers. Regardless > > of what the spec says. > > BGP is not the point. Consider e.g.: > > [attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > > Now the attacker can send packets with a fec0::/10 source > address to the > customer -- no one will block them unless they're > explicitly configured as > site borders -- before the customer itself. And if the > customer does not > block them, we're in for very serious trouble. => So you're talking about two misconfigured sites and you didn't say, where is the attack ? Also even if this happens it's a one-way communication because if the customer tries to reply packets will go nowhere. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 05:21:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDLr29028059; Thu, 31 Oct 2002 05:21:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDLrEx028058; Thu, 31 Oct 2002 05:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDLn29028046 for ; Thu, 31 Oct 2002 05:21: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 g9VDLvMq017383 for ; Thu, 31 Oct 2002 05:21:58 -0800 (PST) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26941 for ; Thu, 31 Oct 2002 06:21:57 -0700 (MST) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VDLgur017405; Thu, 31 Oct 2002 08:21:43 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 08:21:00 -0500 Message-ID: <3DC12F46.5020004@nc.rr.com> Date: Thu, 31 Oct 2002 08:25:26 -0500 From: Brian Haberman Organization: No Organization Here 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: Ole Troan CC: Jun-ichiro itojun Hagino , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <20021030214740.B731F7B9@starfruit.itojun.org> <7t5pttry060.fsf@mrwint.cisco.com> <3DC09071.60706@nc.rr.com> <7t58z0fcocl.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: > [...] > > >>The biggest hit is actually in the forwarding. Each packet >>gets at least one additional table lookup (for the incoming >>zone id). Then there are the checks to ensure that the source >>address is valid (e.g. a site-local SA and global DA trying >>to cross a site border). > > > you have to do the outgoing check for link-locals anyway. Right, but the check for LL in the SA does not require retrieving a zone id that has to be used in the forwarding decision. > > >>The extra cost? Performance drops around 25-30% for a SBR >>between 3 sites. Of course, this was all software based, >>but even a hardware-based solution will take the extra lookup >>hits. > > > I don't see a performance drop in our implementation. an additional > table lookup is not needed for forwarding. you need to figure out the > scope of the DA of course, but that is needed for link-local/multicast > anyway. What protocol is your implementation of SL routing utilizing? How many sites are configured on the router? 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 Oct 31 05:24:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDOb29028118; Thu, 31 Oct 2002 05:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDOaVw028117; Thu, 31 Oct 2002 05:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDOX29028110 for ; Thu, 31 Oct 2002 05:24: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 g9VDOfbB012307 for ; Thu, 31 Oct 2002 05:24:41 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29427 for ; Thu, 31 Oct 2002 05:24:36 -0800 (PST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VDO7ib024431; Thu, 31 Oct 2002 08:24:07 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 08:24:28 -0500 Message-ID: <3DC12FEC.4020304@nc.rr.com> Date: Thu, 31 Oct 2002 08:28:12 -0500 From: Brian Haberman Organization: No Organization Here 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: Mark Smith CC: alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Richard Draves'" , "'Keith Moore'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <082901c28069$6b1a6ad0$4b194104@eagleswings> <3DC091D1.7010405@nc.rr.com> <1036032752.11151.391.camel@dupy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark Smith wrote: > > On Thu, 2002-10-31 at 13:13, Brian Haberman wrote: > >> >>Tony Hain wrote: >> >>>Mark Smith wrote: >>> >>> >>>>... >>>>On a related topic, if I was to stuff up my site local >>>>filters at the edge of my site, would my network then become >>>>part of my ISPs site local network ? >>> >>> >>>You would both have to make an error to get the two IGPs tied together. >>> >>> >>> >>>>In the proposed >>>>site-local models, are sites adjacent, or are they separated >>>>by segments that only have a global address assignments (eg >>>>the BGP AS model vs the OSPF area model) ? >>> >>> >>>I remember this discussion a few months back, but I don't remember the >>>conclusion. Maybe Ole does. >> >>The following is a proposal that was discussed amongst the >>scoped addr arch authors and the ADs. This model would address >>the issue of having adjacent sites quite nicely. >> >> -- -- >> --| |-----------| |-- >> -- -- >> >> <--site 1--> <-dummy site-> <-- site 2 --> >> >>Brian > > > Thanks Brian, that make sense, and clears up my concerns about a single router being the site-local security device for both the provider and the customer. > > Sorry if I'm asking dumb questions, I'm just thinking about how I might > use site local addressing if I was to build an Australia wide IPv6 based > enterprise network, interconnecting the main capital cities. > > As an example, I can see three different ways I could site-local address > the 8 capital cities we have down here (for those who may not be aware, > we have something like at least 500 kilometers between capital cities > down here) : > > * site-local boundary at the edge of each city. wan links between cities > would be treated as dummy sites as per your example above. > > * delete the dummy sites in the previous model, and extend the > site-local boundary of one of the main sites out to the edge of all the > other sites eg the Sydney site local addressing would finish at the edge > of the Melbourne, Adelaide etc site local boundary > > * with 54 bits of subnet address space available in the site-local > fec0::/10 address space, it would be very tempting to just treat the > whole of Australia as one big site, and avoid site boundary routing > configuration issues completely. > > Obviously my last two models don't really fit the idea that site-local > addressing is to cover a single geographical site. > > Are there any documents / drafts / email threads that discuss various > possible site local addressing / boundary models I can have a read of ? In your scenario, I would seriously consider Tony's proposal that site borders be the same as IGP/EGP boundaries. You could very easily run each capital city as an IGP/site and interconnect them via BGP. The BGP connectivity would be the "dummy site" described above. 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 Oct 31 05:26:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDQe29028160; Thu, 31 Oct 2002 05:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDQeBa028159; Thu, 31 Oct 2002 05:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDQb29028152 for ; Thu, 31 Oct 2002 05:26:37 -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 g9VDQjMq018043 for ; Thu, 31 Oct 2002 05:26:45 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19430 for ; Thu, 31 Oct 2002 06:26:40 -0700 (MST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VDQ8iZ027789; Thu, 31 Oct 2002 08:26:08 -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, 31 Oct 2002 08:26:38 -0500 Message-ID: <3DC13065.1070007@nc.rr.com> Date: Thu, 31 Oct 2002 08:30:13 -0500 From: Brian Haberman Organization: No Organization Here 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: Margaret Wasserman CC: Ole Troan , Jun-ichiro itojun Hagino , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <3DC09071.60706@nc.rr.com> <20021030214740.B731F7B9@starfruit.itojun.org> <7t5pttry060.fsf@mrwint.cisco.com> <3DC09071.60706@nc.rr.com> <5.1.0.14.2.20021030220046.02e70b30@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >> >> I don't see a performance drop in our implementation. an additional >> table lookup is not needed for forwarding. you need to figure out the >> scope of the DA of course, but that is needed for link-local/multicast >> anyway. > > > The issue is that you also have to check the source address and drop > the packet if you would be crossing a scope boundary for the source > address... > > I think that a lot of routers already (in IPv4) have the capability > of doing fast classification/filtering based on both source and > destination addresses (among other things), so I don't know how much > of a performance hit this will cause for a hardware-based routers. > And, as was already pointed out, you need to do it for link-local > addresses, anyway. Right. The data points I provided were for one possible implementation of a RIB combined with a software-only router. I can envision several very useful optimizations to do SL routing/forwarding in hardware. 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 Oct 31 05:29:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDTD29028247; Thu, 31 Oct 2002 05:29:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDTDKc028246; Thu, 31 Oct 2002 05:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDTA29028239 for ; Thu, 31 Oct 2002 05:29:10 -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 g9VDTIMq018525 for ; Thu, 31 Oct 2002 05:29:19 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20476 for ; Thu, 31 Oct 2002 06:29:13 -0700 (MST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VDSniZ002146; Thu, 31 Oct 2002 08:28:49 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 08:28:46 -0500 Message-ID: <3DC13106.6030209@nc.rr.com> Date: Thu, 31 Oct 2002 08:32:54 -0500 From: Brian Haberman Organization: No Organization Here 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: "Bound, Jim" CC: alh-ietf@tndh.net, Tim Hartrick , ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Limiting the Use of Site-Local References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B647@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: > Tony, > > What I want is a simple draft that says site-locals will not be > forwarded out of the site? > Brian Haberman et als work had that wordage but the other parts are far > from consensus. > What we could do is have Brian reduce to one draft working with Ole a > statement that this will not happen. We need a bit more than trust me > it won't happen. For those of you that have been around this topic for awhile, the scoped addressing architecture document grew out of a draft I wrote on the routing and forwarding aspects of SLs. Is there consensus to have a standalone doc that talks about those issues only? 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 Oct 31 05:45:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDj829028507; Thu, 31 Oct 2002 05:45:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDj7gk028506; Thu, 31 Oct 2002 05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDj429028499 for ; Thu, 31 Oct 2002 05:45: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 g9VDjDbB015245 for ; Thu, 31 Oct 2002 05:45:13 -0800 (PST) Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10259 for ; Thu, 31 Oct 2002 05:45:07 -0800 (PST) From: William_G_Allmond@notes.tcs.treas.gov Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.5/8.12.5) with SMTP id g9VDXl7v017560; Thu, 31 Oct 2002 08:33:47 -0500 (EST) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 31 Oct 2002 13:44:57 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-3.net.treas.gov (8.12.3/8.12.3) with ESMTP id g9VDipoQ018933; Thu, 31 Oct 2002 08:44:51 -0500 (EST) Sensitivity: Subject: RE: Limiting the Use of Site-Local To: "Hesham Soliman (EAB)" Cc: "'Pekka Savola'" , Richard Draves , ipng@sunroof.eng.sun.com Date: Thu, 31 Oct 2002 08:44:50 -0500 Message-ID: X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 10/31/2002 08:44:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ladies and Gentlemen, First, please excuse my lack of background and intellectual knowledge in all this discussion. Many of the comments that I have read over the past few weeks regarding this seem to revolve around the "theory" of how it should work. Theory is great. Many of the people in this group that post are from acedemia and research areas. I don't see too many posts from people that are actually trying to make this all work. The comments that "NAT shouldn't be used in IPv6 since we will have more than enough IPs" is also great, in THEORY! Did we all think that we would have enough IP numbers when IPv4 was started? I work for a federal agency that has over 6,000,000 devices that need IP numbers. Most need access to the "outside" world. However, do I want all of these devices visible to the out side world? NO! Yes, we have border routers and firewalls that block access from many of the "undesirables" that are out there. Even if we get enough IPv6 numbers to ensure that every device can have a unique number, we will still use NAT. Ok, federal government and leading edge technology go together like military intelligence. The use of site-local is a great proposal. What I think should be done is just like in the IPv4 world, reserve a block (or a couple of blocks) of numbers that are non-routable. This will allow companies to know what nubers they are to use when setting up site-local numbers based on the number of devices. Now, if I have misunderstood the entire context of this post, please refer back to my opening sentence. Gary Allmond -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 05:48:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDmW29028546; Thu, 31 Oct 2002 05:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDmWB4028545; Thu, 31 Oct 2002 05:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDmS29028535 for ; Thu, 31 Oct 2002 05:48:28 -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 g9VDmbMq021494 for ; Thu, 31 Oct 2002 05:48:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00191 for ; Thu, 31 Oct 2002 06:48:31 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA17745; Thu, 31 Oct 2002 05:48:19 -0800 (PST) Message-Id: <5.1.0.14.2.20021031075124.02e76b30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 08:48:48 -0500 To: "Brian Zill" From: Margaret Wasserman Subject: RE: Default site-local behavior for routers 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 Hi Brian, > > I'm not sure that it does much, though, to address the issues > > that site-locals raise for transport protocols, applications, > > DNS and management protocols. Am I missing something? > >Well, this is the ipv6 working group's mailing list after all. We've >been admonished before for messing around in other group's layers. But, we are responsible for the impact that our decisions have on other layers. The impacts on all layers must be considered in the "costs" associated with an architectural decision. Also, those other WGs/areas have not shown a lot of willingness to accept & document the implications of the side-by-side use of global and site-local addressing, which might make us re-examine whether or not this is a good architectural construct. I'm not quite sure how the IETF is suppose to work when one group is making architectural decisions that will have wide-ranging implications for other groups. I suppose one possibility is that the group making the architectural decisions could forge ahead and trust the IESG to decide whether or not those decisions are reasonable in the bigger picture... Is that how folks think it should work? Another possibility is that the group defining the architecture could take responsibility for its wider implications. I guess I'd prefer that second choice, but I guess it could also be described as "messing around in other group's layers"... >But for what it's worth: I'm not aware of any problems scoped addresses >cause for transport protocols, the modifications I had to make to our >TCP implementation were straight-forward and obvious. TCP and UDP are fairly obvious -- include a zone ID as part of the connection identification. Site-locals are more complex for other transport protocols, such as SCTP, SIP, etc. There is an individual draft out (Steve Deering was one of the authors) that describes the mechanisms needed to make SCTP work with site-locals. I don't know if this has been defined for SIP. Does anyone know? And, what about non-IETF transport and session layers? One of the issues is that the impact of site-locals is not limited to the network layer -- each upper level protocol is impacted individually. >Most applications >don't pass around addresses in the data stream, and I've already >explained in other email how the few that do can handle the issue. Right... All of the applications (current and potential future applications) that are negatively impacted by IPv4 NAT will be impacted by the use of IPv6 site-local addressing on globally- attached networks. I think that we understand what the list is for current applications, and only a few IETF applications (FTP, DNS, etc.) are impacted. There are also a lot of non-IETF applications (games, conferencing software, etc.) that will be impacted. And, unlike the NAT case, we can't really minimize these impacts through ALGs in the border routers, so each of these applications will have to deal with IPv6 site-local addressing (if present) separately. I am more concerned, though, by the potential impact on future applications. Many people point to NAT as an inhibitor of new application development and deployment -- will IPv6 site-local addressing present a similar hurdle? >Others have spoken up with DNS solutions. Plus it is not clear to me >that we need a DNS solution. Even Keith says "DNS should not be a MUST. >not all applications need to use it. Also, DNS is a separate service >from IP. IP should not be thought to be dependent on DNS." Personally, >I think site-locals are a big win even if I only ever look them up in a >hosts file. Interesting viewpoint... Personally, I think that we will get all of the costs of site-local addressing and none of the benefits if we encourage their use on globally-connected networks but don't figure out a way to get them into the DNS. >Finally, I'm not aware of any problems site-locals cause >for management protocols either. I think I explained this somewhere else in this thread, but it has been a long thread, so perhaps I'm misremembering... Management protocols (like SNMP) generally involve a network management station that is managing a group of devices. The management station may or may not be on the same link or in the same site as the devices that it is managing. So, the management station may or may not have the context to know which other host a link-local or site-local address refers to. We have one example today where the use of link-local addresses causes a problem for management protocols. IPv6 routing protocols have been defined to use link-local addresses for their peers, which means that a management station that downloads MIB information from a router cannot use the IP addresses in the MIB to unambiguously identify and/or reach the indicated peers. Site-local addresses aren't used enough to have caused a problem, yet. But, their widespread use would cause similar problems in unambiguously identifying and reaching the other end of a long- lived connection, for example. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 05:53:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDro29028646; Thu, 31 Oct 2002 05:53:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VDrocp028645; Thu, 31 Oct 2002 05:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VDrk29028635 for ; Thu, 31 Oct 2002 05:53:46 -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 g9VDrtMq022196 for ; Thu, 31 Oct 2002 05:53:55 -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 GAA18980 for ; Thu, 31 Oct 2002 06:53:47 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA19725; Thu, 31 Oct 2002 05:53:37 -0800 (PST) Message-Id: <5.1.0.14.2.20021031085258.02e80b70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 08:54:46 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E3E2@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >There's been a lot of noise here lately, without real reasons, and it >has not produced much results either. At the point where you believe that a mail thread has reached the end of its useful life, you should stop responding. When everyone feels that way, it will end. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 06:13:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEDu29028819; Thu, 31 Oct 2002 06:13:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VEDueR028818; Thu, 31 Oct 2002 06:13:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEDr29028811 for ; Thu, 31 Oct 2002 06:13:53 -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 g9VEE1Mq025271 for ; Thu, 31 Oct 2002 06:14:01 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25959 for ; Thu, 31 Oct 2002 06:13:56 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA28925; Thu, 31 Oct 2002 06:13:38 -0800 (PST) Message-Id: <5.1.0.14.2.20021031085643.02e83b70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 09:11:27 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E3E3@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:05 PM 10/30/02, Michel Py wrote: >Margaret, > > > Margaret Wasserman wrote: > > You have made a statement that the use of IPv6 > > site-local addresses (as opposed to globally > > unique addresses) will increase the security > > of a private network. And, I still don't > > understand the basis for that claim. > >Semantics: I would have said "globally routable" instead of "globally >unique", as some mechanisms such as including the ASN in the upper bits >of a site-local address could make it globally unique and not globally >routable. That being said, the reasons the mechanism mentioned above has >not convinced is because it was a disguised globally routable address >anyway. I think that this is the source of our misunderstanding. I am _not_ operating under the assumption that all globally-unique addresses will appear in global routing tables. If I want to have a private network, I should be able to get a globally unique (routable, but _not_ necessarily globally routed) address, and _not_ have my ISP advertise that prefix into the global routing tables. If my ISP's policy (or some higher-level policy) requires that I get a second /48 in order to have address space that isn't advertised, I could just get a second /48... Of course, I don't have to simply trust my ISP not to inject my private network addresses into the global routing tables -- I can also run filters on my edge routers that don't allow traffic from/to links outside of my private network using those addresses. As far as I can tell, this approach has all of the putative advantages of site-local addressing, without the problems caused by using the same addresses on every private network (creating ambiguity and the potential for traffic to be sent to the wrong node -- same address, wrong site). Upper-level protocols would not have to be aware of these addresses as anything special, and all of the costs associated with private addressing would accrue to the people who actually want to use them -- they'd have to decide whether or not to run two-faced DNS, how to make sure that globally-routed addresses are used to talk to the outside, etc. Site-local addresses could continue to be useful in networks that are not routed (at all) to the global network. This would include isolated sites, non-Internet-connected sites within cars and planes, etc. I actually _agree_ that it would be better if I could obtain provider-independent global addresses. But perhaps that is a different fight for a different day... Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 06:15:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEF329028836; Thu, 31 Oct 2002 06:15:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VEF2d4028835; Thu, 31 Oct 2002 06:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEEx29028828 for ; Thu, 31 Oct 2002 06:14:59 -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 g9VEF8Mq025466 for ; Thu, 31 Oct 2002 06:15:08 -0800 (PST) Received: from mail.nosense.org (57.cust1.nsw.dsl.ozemail.com.au [203.103.156.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22640 for ; Thu, 31 Oct 2002 06:15:02 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 16ED33B371; Fri, 1 Nov 2002 01:14:59 +1100 (EST) Subject: Re: Default site-local behavior for routers From: Mark Smith To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200210311312.g9VDCN011123@astro.cs.utk.edu> References: <200210311312.g9VDCN011123@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 01 Nov 2002 01:14:59 +1100 Message-Id: <1036073700.11151.483.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does this make me a terrorist network administrator, for trying to help by showing how I might try to use one of the features of IPv6 in the real world ? Please do not bring up terrorism on this mailing list, not only is it in-appropriate, it is in particularly bad taste after the recent bombings in Bali. I'm hoping you haven't forgotten the sad events that occurred in your country just over twelve months ago. We here in Australia certainly haven't. As Vint Cerf wrote in a RFC recently, The Internet is for Everyone. Once everyone has it (I'd say one of the fundamental inherent goals of IPv6), hopefully the world can become a more tolerant place through communication, allowing better understanding of different peoples view points and beliefs. Hopefully the world will become small enough that there will eventually be no "us and them". Your views seem to me to be similar to those that cause terrorism in the first place. If they aren't, then using terrorism and the reactions to terrorism as an example of why a feature should or shouldn't be implemented in IETF developed protocols is offensive, insensitive, and irrelevant. On Fri, 2002-11-01 at 00:12, Keith Moore wrote: > > Enough managers of real networks created them, and still demand them > > that despite your claim that there is no need, there is a requirement > > that we provide something. > > that's like saying that we have to do _something_ about bin Laden, > so we might as well bomb a few thousand people who have nothing > to do with him. yes, that kind of logic is commonly used. that > doesn't make it right. > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 06:17:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEHY29028865; Thu, 31 Oct 2002 06:17:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VEHY4j028864; Thu, 31 Oct 2002 06:17:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEHU29028857 for ; Thu, 31 Oct 2002 06:17:30 -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 g9VEHdMq025928 for ; Thu, 31 Oct 2002 06:17:39 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28029 for ; Thu, 31 Oct 2002 06:17:33 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9VEHSO22808; Thu, 31 Oct 2002 16:17:28 +0200 Date: Thu, 31 Oct 2002 16:17:28 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C4E@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 31 Oct 2002, Hesham Soliman (EAB) wrote: > > > => Forward them where?? I can't imagine BGP not filtering > > > SLs coming from the downstream customers. Regardless > > > of what the spec says. > > > > BGP is not the point. Consider e.g.: > > > > [attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > > > > Now the attacker can send packets with a fec0::/10 source > > address to the > > customer -- no one will block them unless they're > > explicitly configured as > > site borders -- before the customer itself. And if the > > customer does not > > block them, we're in for very serious trouble. > > => So you're talking about two misconfigured > sites and you didn't say, where is the attack ? One misconfigured site, of the victim. ISP doesn't need to care about them, and Internet certainly doesn't. The attackers site wasn't explicitly configured to use site-locals (they probably even don't use them -- only globals), so it isn't blocked in their routers -- this is a feature of your interpretation of the addrarch. > Also even if this happens it's a one-way > communication because if the customer tries > to reply packets will go nowhere. If you have e.g. security hole in a protocol using UDP, one-way communication is more than enough to exploit it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 06:33:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEX229029104; Thu, 31 Oct 2002 06:33:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VEX2KO029103; Thu, 31 Oct 2002 06:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VEWw29029096 for ; Thu, 31 Oct 2002 06:32:58 -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 g9VEX6Mq002703 for ; Thu, 31 Oct 2002 06:33:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01277 for ; Thu, 31 Oct 2002 07:33:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VEWv012304; Thu, 31 Oct 2002 09:32:57 -0500 (EST) Message-Id: <200210311432.g9VEWv012304@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "01 Nov 2002 01:14:59 +1100.") <1036073700.11151.483.camel@dupy> Date: Thu, 31 Oct 2002 09:32:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does this make me a terrorist network administrator, for trying to help > by showing how I might try to use one of the features of IPv6 in the > real world ? No, of course not. It's just that recent events have provided such glaring examples of the utter stupidity of arguments of the form "we must do _something_, even though it won't help, and will probably do harm" that these examples immediately come to my mind whenever I see the phenomenon happening. To me these examples are so obvious that I have a hard time thinking of other examples of this phenomenon to cite. Such arguments are quite common. Thankfully most of the real-world examples of this kind of reasoning do not result in thousands of deaths. Let me attempt a different illustration, this time using an ancient folk tale that may be familiar to some, and which doesn't involve any violence (and which like any good folk tale, is told differently each time): A visitor to Nasrudin's home finds him diligently searching his yard. "What are you looking for?" he said. "My car keys." "Where were you when you last had them?" "Inside my house." "Why aren't you looking for them there?" "Well, the light is better out here. And I had to do _something_ to find them." Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 06:59:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VExp29029260; Thu, 31 Oct 2002 06:59:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VExokQ029259; Thu, 31 Oct 2002 06:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VExk29029252 for ; Thu, 31 Oct 2002 06:59: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 g9VExtMq006881 for ; Thu, 31 Oct 2002 06:59:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16648 for ; Thu, 31 Oct 2002 06:59:49 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VEwS012447; Thu, 31 Oct 2002 09:58:28 -0500 (EST) Message-Id: <200210311458.g9VEwS012447@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: William_G_Allmond@notes.tcs.treas.gov cc: "Hesham Soliman (EAB)" , "'Pekka Savola'" , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 08:44:50 EST.") Date: Thu, 31 Oct 2002 09:58:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > First, please excuse my lack of background and intellectual knowledge in > all this discussion. > > Many of the comments that I have read over the past few weeks regarding > this seem to revolve around the "theory" of how it should work. Theory is > great. Many of the people in this group that post are from acedemia and > research areas. I don't see too many posts from people that are actually > trying to make this all work. Why in the world do you believe that people "from academia and research areas" are not "actually trying to make this all work"? I won't speak for others, but "actually trying to make this all work" is *exactly* what I'm doing! Perhaps we should similarly disregard contributions from .gov addresses on the theory that the US government is just trying to interfere with, or tax, the net's operation (or worse)? It makes about as much sense. I'd prefer that we judge posts on their technical merit rather than assuming things about the purpose or background of people based on their email addresses. Keith p.s. And if you think that NAT is an appropriate mechanism to prevent access to your devices from outside, perhaps you should remedy your "lack of background and intellectual knowledge". There's no security benefit that NAT provides that can't be provided with less disruption by stateful firewalls. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 07:02:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2U29029289; Thu, 31 Oct 2002 07:02:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VF2ULJ029285; Thu, 31 Oct 2002 07:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2Q29029274 for ; Thu, 31 Oct 2002 07:02:26 -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 g9VF2YMq007600 for ; Thu, 31 Oct 2002 07:02:35 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05603 for ; Thu, 31 Oct 2002 08:02:29 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20907; Thu, 31 Oct 2002 07:02:14 -0800 (PST) Message-Id: <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 09:51:17 -0500 To: Brian Haberman From: Margaret Wasserman Subject: Re: Default site-local behavior for routers Cc: Mark Smith , ipng@sunroof.eng.sun.com In-Reply-To: <3DC12E58.4020001@nc.rr.com> References: <200210310529.g9V5TO008795@astro.cs.utk.edu> <1036046913.11151.434.camel@dupy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >>You're probably right. >>On the other hand, as per Ole Troan's earlier email (which I agree >>with), I don't think all router implementations should be required to >>support multi-sites. > >I think Ole's comments apply to specialized routers. If you are >marketing a general purpose router, you almost have to put in >support since you don't know how or where they will be deployed. Not necessarily. Even if we go to the trouble of fully defining how site-local address will work, it is still possible that the market will decide not to support them. If no one builds SBRs, no one will have effective site borders. Are there any commercial routers today that include SBR support? Who has an implementation of an SBR that includes routing protocols? Brian, I know you wrote one with RIPng. Are there others? I'd be very interested in hearing about implementation experiences. Does anyone have a SIP or SCTP implementation that will work in a multi-sited environment? Or other complex applications that pass addressing information? What were your experiences? Does anyone have an operational network that uses site-local addresses to provide private addressing within a globally connected network? Why did you choose to do this? What were your experiences? Please note that I am interested in deployed, operational networks, not theoretical deployments. Have any network administrators installed a two-faced DNS that returns IPv6 site-local addresses within the site, but not externally? How did that work out? >What doesn't really exist is the filtering of prefixes being put >into route exchange messages based on an arbitrary index (zone >id). > >The other big issue is how the routing table(s) are built and >managed. That can be a big hit on memory/storage space. Brian, could you elaborate on these things? Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 07:02:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2Y29029292; Thu, 31 Oct 2002 07:02:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VF2Xq2029291; Thu, 31 Oct 2002 07:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2T29029281 for ; Thu, 31 Oct 2002 07:02: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 g9VF2bMq007609 for ; Thu, 31 Oct 2002 07:02:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18685 for ; Thu, 31 Oct 2002 07:02:32 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20943; Thu, 31 Oct 2002 07:02:19 -0800 (PST) Message-Id: <5.1.0.14.2.20021031095813.02e6eec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 09:59:11 -0500 To: Mark Smith From: Margaret Wasserman Subject: Re: Default site-local behavior for routers Cc: Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <1036073700.11151.483.camel@dupy> References: <200210311312.g9VDCN011123@astro.cs.utk.edu> <200210311312.g9VDCN011123@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As Vint Cerf wrote in a RFC recently, The Internet is for Everyone. Once >everyone has it (I'd say one of the fundamental inherent goals of IPv6), >hopefully the world can become a more tolerant place through >communication, allowing better understanding of different peoples view >points and beliefs. Hopefully the world will become small enough that >there will eventually be no "us and them". And, hopefully, that's while we're all here -- trying to build an Internet that can deliver on this vision. Mark, thanks for reminding us that we're all really on the same side. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 07:02:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2i29029305; Thu, 31 Oct 2002 07:02:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VF2iAh029304; Thu, 31 Oct 2002 07:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF2b29029294 for ; Thu, 31 Oct 2002 07:02:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VF2jbB028032 for ; Thu, 31 Oct 2002 07:02:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24721 for ; Thu, 31 Oct 2002 07:02:40 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20949; Thu, 31 Oct 2002 07:02:21 -0800 (PST) Message-Id: <5.1.0.14.2.20021031095953.02e53430@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 10:02:58 -0500 To: Pekka Savola From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Hesham Soliman (EAB)" , Richard Draves , In-Reply-To: References: <4DA6EA82906FD511BE2F00508BCF0538044F0C4D@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >BGP is not the point. Consider e.g.: > >[attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > >Now the attacker can send packets with a fec0::/10 source address to the >customer -- no one will block them unless they're explicitly configured as >site borders -- before the customer itself. And if the customer does not >block them, we're in for very serious trouble. Far be it from me to argue the other side in this debate, but... I agree that the packet with a site-local source would get through to the customer's site. But, what serious trouble would this cause? This would only cause trouble, I guess, if the customer's system attributes some special security status to packets that appear to come _from_ a site-local address, which would be quite inadvisable. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 07:06:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF6D29029387; Thu, 31 Oct 2002 07:06:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VF6DID029386; Thu, 31 Oct 2002 07:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VF6229029376 for ; Thu, 31 Oct 2002 07:06:10 -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 g9VF6BMq008281 for ; Thu, 31 Oct 2002 07:06:11 -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 IAA07893 for ; Thu, 31 Oct 2002 08:06:05 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9VF5vP23405; Thu, 31 Oct 2002 17:05:57 +0200 Date: Thu, 31 Oct 2002 17:05:56 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (EAB)" , Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <5.1.0.14.2.20021031095953.02e53430@mail.windriver.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, 31 Oct 2002, Margaret Wasserman wrote: > >BGP is not the point. Consider e.g.: > > > >[attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > > > >Now the attacker can send packets with a fec0::/10 source address to the > >customer -- no one will block them unless they're explicitly configured as > >site borders -- before the customer itself. And if the customer does not > >block them, we're in for very serious trouble. > > Far be it from me to argue the other side in this debate, but... > > I agree that the packet with a site-local source would get > through to the customer's site. But, what serious trouble > would this cause? > > This would only cause trouble, I guess, if the customer's > system attributes some special security status to packets > that appear to come _from_ a site-local address, which would > be quite inadvisable. The whole point (or a big portion of it..) of the "security benefit" of site-local addresses comes from the added trust given to site-local addresses (which by the site's definition, are only reachable from inside the site). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 07:37:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFbI29029674; Thu, 31 Oct 2002 07:37:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VFbHUu029673; Thu, 31 Oct 2002 07:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFbE29029666 for ; Thu, 31 Oct 2002 07:37: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 g9VFbMbB004423 for ; Thu, 31 Oct 2002 07:37:22 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15858 for ; Thu, 31 Oct 2002 08:37:17 -0700 (MST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VFavid002720 for ; Thu, 31 Oct 2002 10:36:58 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 10:36:54 -0500 Message-ID: <3DC14F0E.4000408@nc.rr.com> Date: Thu, 31 Oct 2002 10:41:02 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <200210310529.g9V5TO008795@astro.cs.utk.edu> <1036046913.11151.434.camel@dupy> <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: >> What doesn't really exist is the filtering of prefixes being put >> into route exchange messages based on an arbitrary index (zone >> id). >> >> The other big issue is how the routing table(s) are built and >> managed. That can be a big hit on memory/storage space. > > > Brian, could you elaborate on these things? Sure. One of the issues that I had to deal with in the scoped addr arch was how to represent the concept that multiple RIBs are needed to support site-locals. The conceptual model is that you have a RIB for globals and RIB for each unique site-local zone id in the box. These tables can be implemented in several ways. One way would be to add a zone id entry to a monolithic RIB. This means that uniqueness is based on (prefix,zone id) rather than just on prefix. Another way would be to have separate RIBs (perhaps as an array). Then the lookup entails finding the table that matches the incoming zone id and then the prefix in that table. So, right there we have a more complex indexing structure, but it is not too bad. It looks similar to how some products do VPN support. Another hit is taken in each routing protocol. When the protocol builds its advertisement packet, it must do this selectively. The zone id of the outgoing interface is retrieved and the routing protocol then builds its advertisement using the global RIB and the site-local RIB corresponding to the zone id. This process has to be done for each interface. Does anyone want to hear the gory details on the forwarding plane or is the explanation in the scoped addr arch enough? 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 Oct 31 07:39:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFdI29029691; Thu, 31 Oct 2002 07:39:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VFdI1X029690; Thu, 31 Oct 2002 07:39:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFdE29029683 for ; Thu, 31 Oct 2002 07:39:14 -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 g9VFdNMq014429 for ; Thu, 31 Oct 2002 07:39:23 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06263 for ; Thu, 31 Oct 2002 08:39:17 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VFdBQ1020874; Thu, 31 Oct 2002 16:39:11 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 16:39:11 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C54@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , Margaret Wasserman Cc: "Hesham Soliman (EAB)" , Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 16:39:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I keep hoping that this thread will end but it doesn't :) I'm sure we'll all miss this! comments below > On Thu, 31 Oct 2002, Margaret Wasserman wrote: > > >BGP is not the point. Consider e.g.: > > > > > >[attacker] --- [internet] ---- [ISP] --- [customer w/ > site locals] > > > > > >Now the attacker can send packets with a fec0::/10 > source address to the > > >customer -- no one will block them unless they're > explicitly configured as > > >site borders -- before the customer itself. And if the > customer does not > > >block them, we're in for very serious trouble. > > > > Far be it from me to argue the other side in this debate, but... > > > > I agree that the packet with a site-local source would get > > through to the customer's site. But, what serious trouble > > would this cause? > > > > This would only cause trouble, I guess, if the customer's > > system attributes some special security status to packets > > that appear to come _from_ a site-local address, which would > > be quite inadvisable. > > The whole point (or a big portion of it..) of the "security > benefit" of > site-local addresses comes from the added trust given to site-local > addresses (which by the site's definition, are only > reachable from inside > the site). => Pekka, if all the ISP's between the client in your picture and the detination are stupid enough to not ingress filter the SL source, AND the end site is equally as incompetent, then yes, your client will get there. He will never get anything back though. I'm sorry but I don't see this as a realistic or serious issue. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 07:43:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFhJ29029756; Thu, 31 Oct 2002 07:43:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VFhJJw029755; Thu, 31 Oct 2002 07:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFhG29029748 for ; Thu, 31 Oct 2002 07:43:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VFhPbB005769 for ; Thu, 31 Oct 2002 07:43:25 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20009 for ; Thu, 31 Oct 2002 07:43:19 -0800 (PST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VFh1iZ009694 for ; Thu, 31 Oct 2002 10:43:01 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 10:42:58 -0500 Message-ID: <3DC1507A.7000806@nc.rr.com> Date: Thu, 31 Oct 2002 10:47:06 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers References: <200210310529.g9V5TO008795@astro.cs.utk.edu> <1036046913.11151.434.camel@dupy> <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >>> >>> You're probably right. >>> On the other hand, as per Ole Troan's earlier email (which I agree >>> with), I don't think all router implementations should be required to >>> support multi-sites. >> >> >> I think Ole's comments apply to specialized routers. If you are >> marketing a general purpose router, you almost have to put in >> support since you don't know how or where they will be deployed. > > > Not necessarily. Even if we go to the trouble of fully defining > how site-local address will work, it is still possible that the > market will decide not to support them. If no one builds SBRs, > no one will have effective site borders. I agree that could be a big issue. We can't make vendors put stuff in their boxes and we can't mandate how operators deploy technology. So do we only give them enough rope to make a noose or do we give them enough to use constructively? > > Are there any commercial routers today that include SBR support? None that I know of. > > Who has an implementation of an SBR that includes routing protocols? > Brian, I know you wrote one with RIPng. Are there others? I'd > be very interested in hearing about implementation experiences. I started to do one for OSPF, but ran out of time. 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 Oct 31 07:44:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFix29029788; Thu, 31 Oct 2002 07:44:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VFix0o029787; Thu, 31 Oct 2002 07:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VFit29029777 for ; Thu, 31 Oct 2002 07:44:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VFj3Mq015659 for ; Thu, 31 Oct 2002 07:45:04 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20377 for ; Thu, 31 Oct 2002 08:44:56 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9VFiir23783; Thu, 31 Oct 2002 17:44:45 +0200 Date: Thu, 31 Oct 2002 17:44:44 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Margaret Wasserman , Richard Draves , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C54@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 31 Oct 2002, Hesham Soliman (EAB) wrote: > => Pekka, if all the ISP's between the client in your > picture and the detination are stupid enough > to not ingress filter the SL source, Why should they care about it _at all_? The only one who _should_ be doing it (but for different purposes) is the attacker's ISP, when performing ingress filtering. But seeing the lack of ingress filtering today with IPv4 doesn't really make me believe the situation would be much better with IPv6. > AND the end site is > equally as incompetent, then yes, your client will > get there. [...] The destination site is naturally at fault here -- they should have done it, but perhaps they didn't think it was necessary (after all, all site-local traffic is /dev/null'ed at their border router), or forgot to do it. Happens all the time. > I'm sorry but I don't see this as a realistic or serious > issue. Difference in what people expect to get done with site-locals is a serious issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 08:04:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VG4t29000027; Thu, 31 Oct 2002 08:04:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VG4tqf000025; Thu, 31 Oct 2002 08:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VG4p29000016 for ; Thu, 31 Oct 2002 08:04:51 -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 g9VG50Mq020533 for ; Thu, 31 Oct 2002 08:05:00 -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 JAA29434 for ; Thu, 31 Oct 2002 09:04:54 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 31 Oct 2002 08:04:56 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD292@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhUR1oc8bUNgQQ7mwxHMY+SuU5QAACJKAAAbn5oAAFXRbkA== From: "Michel Py" To: "Bound, Jim" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VG4q29000017 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A Monica strike is what Bill Clinton did a while ago: Make a > lot of noise launching a bunch of cruise missiles at Saddam > to try to get the people's attention away from the fact that > he had a young lady under his desk. > If your at this upcoming IETF I would love to speak to you > about this statement in person OK. So lets go offline and > figure out when we can meet. How about the Hard Rock Café > one night. I would love to delve deeper into your knowledge > of the inner workings of one of our Presidents. Of course I > will share my opinion of your statement but only to you and > in person just btw us ok. Also I was not a supporter of > this President but he was the President. Mind if I bring a > couple of Gulf War Veterans I can probably locate in > Atlanta? Have you ever heard the word "humor"? besides, I did not invent the expression, as this is an American topic and I am not American. You might want to to talk to press cartoonists instead. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 08:17:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGHQ29000123; Thu, 31 Oct 2002 08:17:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VGHQYK000122; Thu, 31 Oct 2002 08:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGHN29000114 for ; Thu, 31 Oct 2002 08:17:23 -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 g9VGHVMq023407 for ; Thu, 31 Oct 2002 08:17:31 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06399 for ; Thu, 31 Oct 2002 09:17:26 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2002 08:17:27 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD294@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKA5NabmhPoeVOtTWC++99e7cWiDQAE97DQ From: "Michel Py" To: "Hesham Soliman (EAB)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VGHN29000115 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Gary Allmond wrote: > The use of site-local is a great proposal. What I think should > be done is just like in the IPv4 world, reserve a block (or a > couple of blocks) of numbers that are non-routable. This will > allow companies to know what nubers they are to use when > setting up site-local numbers based on the number of devices. Thank you. 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 Oct 31 08:18:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGIN29000144; Thu, 31 Oct 2002 08:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VGIMU4000143; Thu, 31 Oct 2002 08:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGIJ29000136 for ; Thu, 31 Oct 2002 08:18: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 g9VGIRbB014031 for ; Thu, 31 Oct 2002 08:18:27 -0800 (PST) Received: from dcntnms01.spectrum-health.org (dcntmta02.spectrum-health.org [167.73.110.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA07216 for ; Thu, 31 Oct 2002 09:18:21 -0700 (MST) From: jeffrey.welch@spectrum-health.org Received: from dcntmta02.spectrum-health.org ([10.100.17.6]) by dcntnms01.spectrum-health.org (SAVSMTP 3.0.0.44) with SMTP id M2002103111121725074 ; Thu, 31 Oct 2002 11:12:17 -0500 Received: by dcntmta02.spectrum-health.org with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 11:12:16 -0500 Message-ID: <3636B731B4B310479DFED87FC055CE13060054F3@dcntmsg05.spectrum-health.org> To: michel@arneill-py.sacramento.ca.us, Jim.Bound@hp.com, mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 11:12:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C280F8.4539B610" 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_01C280F8.4539B610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm wondering what on earth this has to do with the scope of this = mailing list.=20 And a lesson in etiquette is reserved for our non-American friend, Mr. = Py. Please pick up the white courtesy phone. -----Original Message----- From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us]=20 Sent: Thursday, October 31, 2002 11:05 AM To: Bound, Jim; Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local > A Monica strike is what Bill Clinton did a while ago: Make a=20 > lot of noise launching a bunch of cruise missiles at Saddam=20 > to try to get the people's attention away from the fact that=20 > he had a young lady under his desk. > If your at this upcoming IETF I would love to speak to you > about this statement in person OK. So lets go offline and > figure out when we can meet. How about the Hard Rock Caf=E9 > one night. I would love to delve deeper into your knowledge > of the inner workings of one of our Presidents. Of course I > will share my opinion of your statement but only to you and > in person just btw us ok. Also I was not a supporter of > this President but he was the President. Mind if I bring a > couple of Gulf War Veterans I can probably locate in > Atlanta? Have you ever heard the word "humor"? besides, I did not invent the expression, as this is an American topic and I am not American. You might want to to talk to press cartoonists instead. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C280F8.4539B610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Limiting the Use of Site-Local

 I'm wondering what on earth this has to do with = the scope of this mailing list.
 And a lesson in etiquette is reserved for our = non-American friend, Mr. Py. Please pick up the white courtesy = phone.

-----Original Message-----
From: Michel Py [mailto:michel@arneill= -py.sacramento.ca.us]
Sent: Thursday, October 31, 2002 11:05 AM
To: Bound, Jim; Margaret Wasserman
Cc: ipng@sunroof.eng.sun.com
Subject: RE: Limiting the Use of Site-Local

> A Monica strike is what Bill Clinton did a while = ago: Make a
> lot of noise launching a bunch of cruise = missiles at Saddam
> to try to get the people's attention away from = the fact that
> he had a young lady under his desk.

> If your at this upcoming IETF I would love to = speak to you
> about this statement in person OK. So lets go = offline and
> figure out when we can meet.  How about = the Hard Rock Caf=E9
> one night. I would love to delve deeper into = your knowledge
> of the inner workings of one of our Presidents. = Of course I
> will share my opinion of your statement but = only to you and
> in person just btw us ok.  Also I was not = a supporter of
> this President but he was the President. Mind = if I bring a
> couple of Gulf War Veterans I can probably = locate in
> Atlanta?

Have you ever heard the word "humor"? = besides, I did not invent the expression, as this is an American topic = and I am not American.

You might want to to talk to press cartoonists = instead.

Michel.


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

------_=_NextPart_001_01C280F8.4539B610-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 08:25:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGPW29000292; Thu, 31 Oct 2002 08:25:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VGPW7x000290; Thu, 31 Oct 2002 08:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGPT29000279 for ; Thu, 31 Oct 2002 08:25:29 -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 g9VGPbMq025352 for ; Thu, 31 Oct 2002 08:25:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18111 for ; Thu, 31 Oct 2002 09:25:22 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 31 Oct 2002 08:25:24 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD295@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKA+GYjj0iy1YCqTC2kWa3VRTRiIwAAYyXg From: "Michel Py" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VGPT29000280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Talking about etiquette, not posting HTML to the list would be a good beginning. Michel -----Original Message----- From: jeffrey.welch@spectrum-health.org [mailto:jeffrey.welch@spectrum-health.org] Sent: Thursday, October 31, 2002 8:12 AM To: Michel Py; Jim.Bound@hp.com; mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local  I'm wondering what on earth this has to do with the scope of this mailing list.  And a lesson in etiquette is reserved for our non-American friend, Mr. Py. Please pick up the white courtesy phone. -----Original Message----- From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] Sent: Thursday, October 31, 2002 11:05 AM To: Bound, Jim; Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local > A Monica strike is what Bill Clinton did a while ago: Make a > lot of noise launching a bunch of cruise missiles at Saddam > to try to get the people's attention away from the fact that > he had a young lady under his desk. > If your at this upcoming IETF I would love to speak to you > about this statement in person OK. So lets go offline and > figure out when we can meet.  How about the Hard Rock Café > one night. I would love to delve deeper into your knowledge > of the inner workings of one of our Presidents. Of course I > will share my opinion of your statement but only to you and > in person just btw us ok.  Also I was not a supporter of > this President but he was the President. Mind if I bring a > couple of Gulf War Veterans I can probably locate in > Atlanta? Have you ever heard the word "humor"? besides, I did not invent the expression, as this is an American topic and I am not American. You might want to to talk to press cartoonists instead. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page:                      http://playground.sun.com/ipng FTP archive:                      ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 08:39:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGdI29000455; Thu, 31 Oct 2002 08:39:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VGdIig000454; Thu, 31 Oct 2002 08:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VGdE29000447 for ; Thu, 31 Oct 2002 08:39:14 -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 g9VGdNbB019123 for ; Thu, 31 Oct 2002 08:39:23 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23569 for ; Thu, 31 Oct 2002 09:39:17 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 08:37:42 -0800 Reply-To: From: "Tony Hain" To: , "'Hesham Soliman \(EAB\)'" Cc: "'Pekka Savola'" , "'Richard Draves'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 08:37:34 -0800 Message-ID: <00ad01c280fb$d275d740$237ba8c0@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.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VGdF29000448 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gary, You have correctly assessed what this thread is about. The argument boils down to 'we should prevent you from doing harm to yourself by insisting that scissors were never invented'. That way we don't have to keep telling you not to run with them. Thinking about it in the shower this morning, it occurs to me that the disconnect stems from a strong desire to get out of the swamp we find ourselves in with IPv4. The problem is that simply standing on the outside of the swamp and saying 'jump over here' will never work. We have to meet people where they are and provide them with stepping stones that allow them to take the incremental step to work their way out. People that run production networks need to keep focus on the real expectations of that first step, or we run the risk of putting it too far away which just prevents progress. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of > William_G_Allmond@notes.tcs.treas.gov > Sent: Thursday, October 31, 2002 5:45 AM > To: Hesham Soliman (EAB) > Cc: 'Pekka Savola'; Richard Draves; ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > > Ladies and Gentlemen, > > First, please excuse my lack of background and intellectual > knowledge in all this discussion. > > Many of the comments that I have read over the past few weeks > regarding this seem to revolve around the "theory" of how it > should work. Theory is great. Many of the people in this > group that post are from acedemia and research areas. I don't > see too many posts from people that are actually trying to > make this all work. > > The comments that "NAT shouldn't be used in IPv6 since we > will have more than enough IPs" is also great, in THEORY! Did > we all think that we would have enough IP numbers when IPv4 > was started? I work for a federal agency that has over > 6,000,000 devices that need IP numbers. Most need access to > the "outside" world. However, do I want all of these devices > visible to the out side world? NO! Yes, we have border > routers and firewalls that block access from many of the > "undesirables" that are out there. > > Even if we get enough IPv6 numbers to ensure that every > device can have a unique number, we will still use NAT. Ok, > federal government and leading edge technology go together > like military intelligence. The use of site-local is a great > proposal. What I think should be done is just like in the > IPv4 world, reserve a block (or a couple of blocks) of > numbers that are non-routable. This will allow companies to > know what nubers they are to use when setting up site-local > numbers based on the number of devices. > > Now, if I have misunderstood the entire context of this post, > please refer back to my opening sentence. > > Gary Allmond > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 31 09:00:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VH0W29000618; Thu, 31 Oct 2002 09:00:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VH0VLn000617; Thu, 31 Oct 2002 09:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VH0S29000609 for ; Thu, 31 Oct 2002 09:00: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 g9VH0bMq004496 for ; Thu, 31 Oct 2002 09:00:37 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09843 for ; Thu, 31 Oct 2002 10:00:11 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 09:00:00 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 08:59:52 -0800 Message-ID: <00c301c280fe$eec76a50$237ba8c0@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.3416 In-Reply-To: <5.1.0.14.2.20021031085258.02e80b70@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VH0T29000610 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >There's been a lot of noise here lately, without real > reasons, and it > >has not produced much results either. > > At the point where you believe that a mail thread has reached > the end of its useful life, you should stop responding. When > everyone feels that way, it will end. The problem with that theory is that the consensus is generally measured as a thread is dying down. If everyone that believes this attempt to subvert a long standing architectural decision is a waste, suddenly stopped sending, there would be a proclamation that SL is revoked. After all, there would be clear evidence that everyone that felt strongly enough to comment wanted it removed... The real point is that some app developers have figured out that having an architected space makes it easier for them to know when connectivity will be broken, but others have not. The arguments by those that have not figured it out are much more about disallowing 'broken connectivity' than they are about figuring out when that happens. Reality says that network managers want to, and will break connectivity when it is in their interest, and no amount of IETF documentation to the contrary will prevent that. We can choose to leave the network managers to figure out their own adhoc mechanisms, or we can put them in a structured space so that apps will have a chance to react appropriately. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:05:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VH5e29000776; Thu, 31 Oct 2002 09:05:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VH5e5h000775; Thu, 31 Oct 2002 09:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VH5b29000768 for ; Thu, 31 Oct 2002 09:05:37 -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 g9VH5jMq006201 for ; Thu, 31 Oct 2002 09:05:45 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13556 for ; Thu, 31 Oct 2002 10:05:34 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 09:05:38 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Brian Haberman'" Cc: "'Mark Smith'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 09:05:30 -0800 Message-ID: <00c901c280ff$b8251910$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > Are there any commercial routers today that include SBR support? By definition, every IGP/EGP transition is at least one example of site border, so the answer to your question is yes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 09:17:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHHL29000996; Thu, 31 Oct 2002 09:17:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHHLi0000995; Thu, 31 Oct 2002 09:17:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHHH29000988 for ; Thu, 31 Oct 2002 09:17: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 g9VHHJMq009820 for ; Thu, 31 Oct 2002 09:17:19 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23380 for ; Thu, 31 Oct 2002 10:17:13 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2002 09:17:15 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3E5@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKA59Tg9unh+sIeQ9e4YRW5mBF2pgAEnGLg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHHI29000989 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, [you have not adressed the security issues?] > I am _not_ operating under the assumption that all > globally-unique addresses will appear in global routing > tables. If I want to have a private network, I should > be able to get a globally unique (routable, but _not_ > necessarily globally routed) address, and _not_ have my > ISP advertise that prefix into the global routing tables. Problem is, nobody has bought this yet, because these addresses are PI, whatever you might call them, and will be misused and leaked to the defaultless table one day or the other, especially in the lack of a multihoming solution. > I actually _agree_ that it would be better if I could > obtain provider-independent global addresses. But > perhaps that is a different fight for a different > day... I have co-authored a draft on the topic, but it's not going anywhere anytime soon; in the meantime, deployment of Ipv6 needs *something* comparable to site-locals, or else people will hijack prefixes anyway. > Site-local addresses could continue to be useful in > networks that are not routed (at all) to the global > network. This would include isolated sites, non > Internet-connected sites within cars and planes, etc. This needs to be clarified. How many "networks" or "sites" is the diagram below, not including the ISP nor the first router that I included only for reference purposes? <------------------- Global Addresses ---------------><-- SL addr --> +-----+ | ISP | +--+--+ ! +--+-------+ +----------+ +----------+ +----------+ | Router A +--+ Firewall +--+--+ Firewall +--+--+ Router B +----+ +----------+ +----------+ | +----------+ | +----------+ | | | | +---+--+ +--+---+ +----+----+ | DFZ | | Host | | Control | | Host | +------+ | Device | +------+ +---------+ <---------------------- Network ----------------------> In my reading, one. I am all for a draft or something that says that the part that has SL addresses can never talk to anybody past the outside firewall, but it needs to talk to the regular hosts that have global addresses between the first firewall and router B, and possibly to the DFZ hosts. What concerns me is that this network would not be considered an isolated network. Without getting in the details of stack implementation and scopes, it does not appear impossible to me to have the two sides communicate. I have configured many IPv4 sites that would match the diagram above, replacing SLs with RFC1918, that did not have NAT, and where the network's internal routing table contained both public and private addresses. Someone still has to explain me what's wrong with the picture above. 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 Oct 31 09:24:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHOk29001071; Thu, 31 Oct 2002 09:24:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHOkR9001070; Thu, 31 Oct 2002 09:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHOg29001063 for ; Thu, 31 Oct 2002 09:24:42 -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 g9VHOobB002070 for ; Thu, 31 Oct 2002 09:24:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25746 for ; Thu, 31 Oct 2002 10:24:43 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VHOR013096; Thu, 31 Oct 2002 12:24:28 -0500 (EST) Message-Id: <200210311724.g9VHOR013096@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 08:59:52 PST.") <00c301c280fe$eec76a50$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 12:24:27 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The real point is that some app developers have figured out that having > an architected space makes it easier for them to know when connectivity > will be broken, I wish you'd stop making such blatently false statements. It is insulting to everyone in this group and it doesn't contribute usefully to the discussion. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:27:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHRJ29001135; Thu, 31 Oct 2002 09:27:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHRJwe001134; Thu, 31 Oct 2002 09:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHRE29001126 for ; Thu, 31 Oct 2002 09:27: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 g9VHRMbB002871 for ; Thu, 31 Oct 2002 09:27:23 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01605 for ; Thu, 31 Oct 2002 10:27:17 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VHPp013115; Thu, 31 Oct 2002 12:25:51 -0500 (EST) Message-Id: <200210311725.g9VHPp013115@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: William_G_Allmond@notes.tcs.treas.gov, "'Hesham Soliman \(EAB\)'" , "'Pekka Savola'" , "'Richard Draves'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 08:37:34 PST.") <00ad01c280fb$d275d740$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 12:25:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thinking about it in the shower this morning, it occurs to me that the > disconnect stems from a strong desire to get out of the swamp we find > ourselves in with IPv4. The problem is that simply standing on the > outside of the swamp and saying 'jump over here' will never work. True enough. And neither will creating an even more complex swamp and saying "hey, try this swamp over here! it's even better!" Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:27:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHRf29001152; Thu, 31 Oct 2002 09:27:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHRfQw001151; Thu, 31 Oct 2002 09:27:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHRZ29001141 for ; Thu, 31 Oct 2002 09:27:35 -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 g9VHRhMq013213 for ; Thu, 31 Oct 2002 09:27: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 JAA06743 for ; Thu, 31 Oct 2002 09:27:38 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 31 Oct 2002 09:27:37 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD298@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhUR1oc8bUNgQQ7mwxHMY+SuU5QAACJKAAAbn5oAAFXRbkAAC88oQ From: "Michel Py" To: "Bound, Jim" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHRZ29001142 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> A Monica strike is what Bill Clinton did a while ago: Make a >> lot of noise launching a bunch of cruise missiles at Saddam >> to try to get the people's attention away from the fact that >> he had a young lady under his desk. > If your at this upcoming IETF I would love to speak to you > about this statement in person OK. So lets go offline and > figure out when we can meet. How about the Hard Rock Café > one night. I would love to delve deeper into your knowledge > of the inner workings of one of our Presidents. Of course I > will share my opinion of your statement but only to you and > in person just btw us ok. Also I was not a supporter of > this President but he was the President. Mind if I bring a > couple of Gulf War Veterans I can probably locate in > Atlanta? Someone tells me that you need to rent a movie called "Wag the dog". 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 Oct 31 09:34:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHYg29001314; Thu, 31 Oct 2002 09:34:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHYgwp001313; Thu, 31 Oct 2002 09:34:42 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHYb29001299 for ; Thu, 31 Oct 2002 09:34:38 -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 g9VHYkMq015385 for ; Thu, 31 Oct 2002 09:34:46 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01136 for ; Thu, 31 Oct 2002 10:33:08 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 09:33:12 -0800 Reply-To: From: "Tony Hain" To: "'Brian Haberman'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 09:33:04 -0800 Message-ID: <00dd01c28103$93376000$237ba8c0@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.3416 In-Reply-To: <3DC14F0E.4000408@nc.rr.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHYc29001300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian is right, the approaches for dealing with independent routing multiple scopes are fairly straight forward. At the same time I suspect that the majority of sites that will use SL, will simply treat them as a set of prefixes to be passed around in their IGP. Since it will require both parties to misconfigure BGP to get those prefixes leaked between enterprises, they will feel more secure about using them (note: I did not say they would have better security, just that they would 'feel more secure'). For this simple reason we need to meet the network manager at his comfort zone and provide a fimilar tool. Yes that appears to create a problem for multi-party apps, but the problem of disconnectedness exists without a defined SL. Since SL makes it clear that there are places where the network will be disconnected, there should be a note to application developers stating what the pitfalls are, along with any known work arounds. Having a clearly defined prefix should make that task easier. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Brian Haberman > Sent: Thursday, October 31, 2002 7:41 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: Default site-local behavior for routers > > > Margaret Wasserman wrote: > > >> What doesn't really exist is the filtering of prefixes > being put into > >> route exchange messages based on an arbitrary index (zone id). > >> > >> The other big issue is how the routing table(s) are built and > >> managed. That can be a big hit on memory/storage space. > > > > > > Brian, could you elaborate on these things? > > Sure. One of the issues that I had to deal with in the > scoped addr arch was how to represent the concept that > multiple RIBs are needed to support site-locals. The > conceptual model is that you have a RIB for globals and RIB > for each unique site-local zone id in the box. > > These tables can be implemented in several ways. One way > would be to add a zone id entry to a monolithic RIB. This > means that uniqueness is based on (prefix,zone id) rather > than just on prefix. Another way would be to have separate > RIBs (perhaps as an array). Then the lookup entails finding > the table that matches the incoming zone id and then the > prefix in that table. > > So, right there we have a more complex indexing structure, > but it is not too bad. It looks similar to how some products > do VPN support. > > Another hit is taken in each routing protocol. When the > protocol builds its advertisement packet, it must do this > selectively. The zone id of the outgoing interface is > retrieved and the routing protocol then builds its > advertisement using the global RIB and the site-local RIB > corresponding to the zone id. This process has to be done > for each interface. > > Does anyone want to hear the gory details on the forwarding > plane or is the explanation in the scoped addr arch enough? > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:34:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHYj29001317; Thu, 31 Oct 2002 09:34:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHYjSS001316; Thu, 31 Oct 2002 09:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHYe29001306 for ; Thu, 31 Oct 2002 09:34:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VHYmMq015394 for ; Thu, 31 Oct 2002 09:34:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07153 for ; Thu, 31 Oct 2002 10:34:42 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 09:33:12 -0800 Reply-To: From: "Tony Hain" To: "'Brian Haberman'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 09:33:04 -0800 Message-ID: <00dd01c28103$93376000$237ba8c0@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.3416 In-Reply-To: <3DC14F0E.4000408@nc.rr.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHYe29001307 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian is right, the approaches for dealing with independent routing multiple scopes are fairly straight forward. At the same time I suspect that the majority of sites that will use SL, will simply treat them as a set of prefixes to be passed around in their IGP. Since it will require both parties to misconfigure BGP to get those prefixes leaked between enterprises, they will feel more secure about using them (note: I did not say they would have better security, just that they would 'feel more secure'). For this simple reason we need to meet the network manager at his comfort zone and provide a fimilar tool. Yes that appears to create a problem for multi-party apps, but the problem of disconnectedness exists without a defined SL. Since SL makes it clear that there are places where the network will be disconnected, there should be a note to application developers stating what the pitfalls are, along with any known work arounds. Having a clearly defined prefix should make that task easier. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Brian Haberman > Sent: Thursday, October 31, 2002 7:41 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: Default site-local behavior for routers > > > Margaret Wasserman wrote: > > >> What doesn't really exist is the filtering of prefixes > being put into > >> route exchange messages based on an arbitrary index (zone id). > >> > >> The other big issue is how the routing table(s) are built and > >> managed. That can be a big hit on memory/storage space. > > > > > > Brian, could you elaborate on these things? > > Sure. One of the issues that I had to deal with in the > scoped addr arch was how to represent the concept that > multiple RIBs are needed to support site-locals. The > conceptual model is that you have a RIB for globals and RIB > for each unique site-local zone id in the box. > > These tables can be implemented in several ways. One way > would be to add a zone id entry to a monolithic RIB. This > means that uniqueness is based on (prefix,zone id) rather > than just on prefix. Another way would be to have separate > RIBs (perhaps as an array). Then the lookup entails finding > the table that matches the incoming zone id and then the > prefix in that table. > > So, right there we have a more complex indexing structure, > but it is not too bad. It looks similar to how some products > do VPN support. > > Another hit is taken in each routing protocol. When the > protocol builds its advertisement packet, it must do this > selectively. The zone id of the outgoing interface is > retrieved and the routing protocol then builds its > advertisement using the global RIB and the site-local RIB > corresponding to the zone id. This process has to be done > for each interface. > > Does anyone want to hear the gory details on the forwarding > plane or is the explanation in the scoped addr arch enough? > > Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:47:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHlJ29001562; Thu, 31 Oct 2002 09:47:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHlJJT001561; Thu, 31 Oct 2002 09:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHlF29001554 for ; Thu, 31 Oct 2002 09:47: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 g9VHlObB009035 for ; Thu, 31 Oct 2002 09:47:24 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16343 for ; Thu, 31 Oct 2002 10:47:18 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 09:47:18 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 09:46:40 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 09:47:17 -0800 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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 09:47:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAiJaCVBonoQDoQoqzADOrBSUQnwAfMj/g From: "Richard Draves" To: "Mark Smith" Cc: X-OriginalArrivalTime: 31 Oct 2002 17:47:17.0905 (UTC) FILETIME=[8E1F9810:01C28105] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHlG29001555 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Obviously my last two models don't really fit the idea that > site-local addressing is to cover a single geographical site. Why do you think that site-local addressing is tied to geography in any way? 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 Thu Oct 31 09:53:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHrl29001661; Thu, 31 Oct 2002 09:53:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHrlY2001660; Thu, 31 Oct 2002 09:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHrh29001653 for ; Thu, 31 Oct 2002 09:53:43 -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 g9VHrpbB011016 for ; Thu, 31 Oct 2002 09:53:52 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22874 for ; Thu, 31 Oct 2002 10:53:46 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 09:50:50 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 09:50:42 -0800 Message-ID: <00e501c28106$09b3f250$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200210311724.g9VHOR013096@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > The real point is that some app developers have figured out that > > having an architected space makes it easier for them to know when > > connectivity will be broken, > > I wish you'd stop making such blatently false statements. It > is insulting to everyone in this group and it doesn't > contribute usefully to the discussion. Please read the following: On Wednesday, October 30, 2002 6:22 PM Brian Zill wrote: > ... Again, the solution > I've outlined is simple, practical, and works today. Since I have first hand knowledge that Brian has actually done the development work to make several applications IPv6 aware, my statement is not blatently false. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 09:57:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHvS29001729; Thu, 31 Oct 2002 09:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VHvRAw001727; Thu, 31 Oct 2002 09:57:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VHvM29001718 for ; Thu, 31 Oct 2002 09:57:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VHvUbB012028 for ; Thu, 31 Oct 2002 09:57:30 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23804 for ; Thu, 31 Oct 2002 10:57:25 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 09:57:12 -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); Thu, 31 Oct 2002 09:57:18 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 09:56:41 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 09:57:19 -0800 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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 09:57:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAvPymL3fnaPRQTneA0tACwjWCqAASY0jg From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 31 Oct 2002 17:57:19.0155 (UTC) FILETIME=[F47F1030:01C28106] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VHvM29001719 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > > Now the attacker can send packets with a fec0::/10 source > address to the customer -- no one will block them unless > they're explicitly configured as site borders -- before the > customer itself. And if the customer does not block them, > we're in for very serious trouble. > > That seemed to be what everyone except me read the ADDRARCH > paragraph to imply. I thought attackers first-hop router (or > at the latest, attackers edge router) should block these > packets automatically. No. At least I read ADDRARCH as meaning that the routers between the attacker and the customer would all be configured (one way or another - either manually or because it's their default configuration) as site boundaries, meaning they would filter the site-local packets. 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 Thu Oct 31 10:04:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VI4029001966; Thu, 31 Oct 2002 10:04:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VI40eo001965; Thu, 31 Oct 2002 10:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VI3u29001958 for ; Thu, 31 Oct 2002 10:03:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VI45Mq025292 for ; Thu, 31 Oct 2002 10:04:05 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21429 for ; Thu, 31 Oct 2002 10:04:00 -0800 (PST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9VI3bif019619 for ; Thu, 31 Oct 2002 13:03:40 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 31 Oct 2002 13:04:03 -0500 Message-ID: <3DC17173.4000404@nc.rr.com> Date: Thu, 31 Oct 2002 13:07:47 -0500 From: Brian Haberman Organization: No Organization Here 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: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves wrote: >>[attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] >> >>Now the attacker can send packets with a fec0::/10 source >>address to the customer -- no one will block them unless >>they're explicitly configured as site borders -- before the >>customer itself. And if the customer does not block them, >>we're in for very serious trouble. >> >>That seemed to be what everyone except me read the ADDRARCH >>paragraph to imply. I thought attackers first-hop router (or >>at the latest, attackers edge router) should block these >>packets automatically. > > > No. At least I read ADDRARCH as meaning that the routers between the > attacker and the customer would all be configured (one way or another - > either manually or because it's their default configuration) as site > boundaries, meaning they would filter the site-local packets. Or if you follow Tony's model, each IGP/EGP boundary would filter them. 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 Oct 31 10:07:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VI7M29002062; Thu, 31 Oct 2002 10:07:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VI7Msi002061; Thu, 31 Oct 2002 10:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VI7I29002051 for ; Thu, 31 Oct 2002 10:07: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 g9VI7RMq026484 for ; Thu, 31 Oct 2002 10:07:27 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01275 for ; Thu, 31 Oct 2002 11:07:21 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:07:20 -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); Thu, 31 Oct 2002 10:07:18 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 10:06:40 -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); Thu, 31 Oct 2002 10:07:19 -0800 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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 10:07:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKA6P5Qlk/zWmGyT0i7YkGz67eQbQAHqDiQ From: "Richard Draves" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 31 Oct 2002 18:07:19.0040 (UTC) FILETIME=[5A0E4000:01C28108] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VI7I29002052 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am _not_ operating under the assumption that all > globally-unique addresses will appear in global routing > tables. If I want to have a private network, I should be > able to get a globally unique (routable, but _not_ > necessarily globally routed) address, and _not_ have my ISP > advertise that prefix into the global routing tables. If my > ISP's policy (or some higher-level policy) requires that I > get a second /48 in order to have address space that isn't > advertised, I could just get a second /48... So we have a site with a globally-routable /48 prefix. Are you saying that instead of using site-local addresses in addition to its global addresses, the site could use a second /48 global prefix that is not globally routable and is filtered at the site boundary? This would be silly. It would be just like site-locals except with a non-standard prefix. It would work worse than site-locals because Default Address Selection wouldn't work properly and because of Keith's issue of distributed apps that do referrals - those apps wouldn't be able to distinguish the two kinds of addresses to do the right thing. 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 Thu Oct 31 10:11:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIBD29002179; Thu, 31 Oct 2002 10:11:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIBDMg002178; Thu, 31 Oct 2002 10:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIBA29002171 for ; Thu, 31 Oct 2002 10:11:10 -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 g9VIBIMq027879 for ; Thu, 31 Oct 2002 10:11:18 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04399 for ; Thu, 31 Oct 2002 11:11:13 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:11:13 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 10:10:33 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:11:12 -0800 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: Default site-local behavior for routers Date: Thu, 31 Oct 2002 10:11:12 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKA787Uoe9fDE0qRYamWfdrXaLrogAGO2DQ From: "Richard Draves" To: "Margaret Wasserman" Cc: X-OriginalArrivalTime: 31 Oct 2002 18:11:12.0653 (UTC) FILETIME=[E54CC3D0:01C28108] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VIBA29002172 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone have an operational network that uses site-local > addresses to provide private addressing within a globally > connected network? Why did you choose to do this? What were > your experiences? Please note that I am interested in > deployed, operational networks, not theoretical deployments. Yes Microsoft operates such a network. > Have any network administrators installed a two-faced DNS > that returns IPv6 site-local addresses within the site, but > not externally? How did that work out? Yes it uses two-faced DNS. It works fine. 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 Thu Oct 31 10:39:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIdm29002667; Thu, 31 Oct 2002 10:39:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIdmNX002666; Thu, 31 Oct 2002 10:39:48 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIdi29002659 for ; Thu, 31 Oct 2002 10:39:44 -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 g9VIdrMq008029 for ; Thu, 31 Oct 2002 10:39:53 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28267 for ; Thu, 31 Oct 2002 10:39:47 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VIdc013463; Thu, 31 Oct 2002 13:39:40 -0500 (EST) Message-Id: <200210311839.g9VIdc013463@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 09:50:42 PST.") <00e501c28106$09b3f250$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 13:39:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > The real point is that some app developers have figured out that > > > having an architected space makes it easier for them to know when > > > connectivity will be broken, > > > > I wish you'd stop making such blatently false statements. It > > is insulting to everyone in this group and it doesn't > > contribute usefully to the discussion. > > Please read the following: > > On Wednesday, October 30, 2002 6:22 PM Brian Zill wrote: > > ... Again, the solution > > I've outlined is simple, practical, and works today. > > Since I have first hand knowledge that Brian has actually done the > development work to make several applications IPv6 aware, my statement > is not blatently false. that lends zero support to the statement you gave earlier. and has already been discussed, there are lots of applications for which SLs don't cause a problem, so the fact the numerous apps have been ported to v6 without major problems is not a compelling case for keeping SLs. apps CANNOT know when connectivity will be broken by use of SLs even if they know whether those SL addresses came in from the same interface, which in general they won't. if you insist that the apps filter SLs when relaying outside of their scope then you're artifically breaking connectivity - the referrer doesn't know whether two nodes with SLs could have communicated directly or not. that and use of SLs doesn't tell the app whether the communication was administratively prohibited, any more than globals do. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 10:43:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIhI29002711; Thu, 31 Oct 2002 10:43:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIhImJ002710; Thu, 31 Oct 2002 10:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIhF29002700 for ; Thu, 31 Oct 2002 10:43: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 g9VIhNbB027451 for ; Thu, 31 Oct 2002 10:43:23 -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 LAA10318 for ; Thu, 31 Oct 2002 11:43:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9VIhEd25420; Thu, 31 Oct 2002 20:43:14 +0200 Date: Thu, 31 Oct 2002 20:43:14 +0200 (EET) From: Pekka Savola To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local 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, 31 Oct 2002, Richard Draves wrote: > > [attacker] --- [internet] ---- [ISP] --- [customer w/ site locals] > > > > Now the attacker can send packets with a fec0::/10 source > > address to the customer -- no one will block them unless > > they're explicitly configured as site borders -- before the > > customer itself. And if the customer does not block them, > > we're in for very serious trouble. > > > > That seemed to be what everyone except me read the ADDRARCH > > paragraph to imply. I thought attackers first-hop router (or > > at the latest, attackers edge router) should block these > > packets automatically. > > No. At least I read ADDRARCH as meaning that the routers between the > attacker and the customer would all be configured (one way or another - > either manually or because it's their default configuration) as site > boundaries, meaning they would filter the site-local packets. This reading of ADDRARCH seems to be in conflict with what you said earlier: --8<-- > [me:] > Some read it (many): > > "if I configure a site here, I must also block site-locals > from spreading > out or false site-locals coming in" > > Some others read it: > > "if I use site-locals here, my upstream router will block > the site-local > addresses from spreading out and prevent anyone from spoofing > site-locals > to my site" > > The latter is how I read it must be implemented -- and > reading Microsoft's implementation and the reason they're > using SL *strongly* suggests they > also have read it that way. There are very probably many others. [Rich:] No, I think you're the only person reading it the latter way. My expectation is that routers will need to be configured to understand site boundaries. A conservative position is that routers by default should regard their interfaces as belonging to different sites, unless they are configured to be in the same site. Or perhaps other aspects of the router's configuration (eg the network prefixes assigned to different interfaces, or the routing protocols in use) could be used to default the site configuration. --8<-- You're making an assumption that folks who don't care about site-locals at all somehow block them. That's much closer to how I read it than the first way, I believe. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 10:47:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIlb29002854; Thu, 31 Oct 2002 10:47:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIlbev002853; Thu, 31 Oct 2002 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIlW29002843 for ; Thu, 31 Oct 2002 10:47:32 -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 g9VIleMq010973 for ; Thu, 31 Oct 2002 10:47:40 -0800 (PST) Received: from starfruit.itojun.org (dhcp1252.nanog26.merit.net [192.35.165.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15454 for ; Thu, 31 Oct 2002 11:47:33 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id CDB3A7B9; Fri, 1 Nov 2002 03:46:39 +0900 (JST) To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Thu, 31 Oct 2002 10:11:12 PST. 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: Default site-local behavior for routers From: Jun-ichiro itojun Hagino Date: Fri, 01 Nov 2002 03:46:39 +0900 Message-Id: <20021031184639.CDB3A7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Does anyone have an operational network that uses site-local >> addresses to provide private addressing within a globally >> connected network? Why did you choose to do this? What were >> your experiences? Please note that I am interested in >> deployed, operational networks, not theoretical deployments. >Yes Microsoft operates such a network. curious: do you run any router which participates to multiple sites? 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 Thu Oct 31 10:48:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VImZ29002902; Thu, 31 Oct 2002 10:48:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VImYMZ002900; Thu, 31 Oct 2002 10:48:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VImT29002887 for ; Thu, 31 Oct 2002 10:48:29 -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 g9VImcMq011346 for ; Thu, 31 Oct 2002 10:48:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14339 for ; Thu, 31 Oct 2002 11:48:32 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VImO013637; Thu, 31 Oct 2002 13:48:24 -0500 (EST) Message-Id: <200210311848.g9VImO013637@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 09:17:15 PST.") <2B81403386729140A3A899A8B39B046405E3E5@server2000> Date: Thu, 31 Oct 2002 13:48:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Problem is, nobody has bought this yet, because these addresses are PI, > whatever you might call them, and will be misused and leaked to the > defaultless table one day or the other, especially in the lack of a > multihoming solution. I don't buy it. If the standards say that ISPs in the public Internet are supposed to filter advertisements for global PI addresses, I'm confident they will get filtered in the vast majority of cases. It's not like the situation with v4 where there are varying levels of gray about which prefixes it's reasonable to advertise. We're talking about a clear-cut distinction here, ideally a single (short) prefix that should be black holed. Of course if individual ISPs want to advertise routes to such prefixes internally, perhaps because they're paid to do so, that's their own business. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 10:48:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VImd29002905; Thu, 31 Oct 2002 10:48:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VImc24002904; Thu, 31 Oct 2002 10:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VImX29002894 for ; Thu, 31 Oct 2002 10:48:33 -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 g9VImfbB029463 for ; Thu, 31 Oct 2002 10:48:42 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01771 for ; Thu, 31 Oct 2002 11:48:36 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 10:48:35 -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); Thu, 31 Oct 2002 10:48:33 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 10:47:54 -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); Thu, 31 Oct 2002 10:48:35 -0800 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: Default site-local behavior for routers Date: Thu, 31 Oct 2002 10:48:35 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKBDfiwcLpEnt3HT9KLRYtfhlolrgAAAzQg From: "Richard Draves" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 31 Oct 2002 18:48:35.0337 (UTC) FILETIME=[1E0B2F90:01C2810E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VImY29002895 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > curious: do you run any router which participates to > multiple sites? Not to my knowledge, but I don't run the routers. 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 Thu Oct 31 10:50:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIod29002993; Thu, 31 Oct 2002 10:50:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIodhE002992; Thu, 31 Oct 2002 10:50:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIoZ29002980 for ; Thu, 31 Oct 2002 10:50:35 -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 g9VIohMq012024 for ; Thu, 31 Oct 2002 10:50:43 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17256 for ; Thu, 31 Oct 2002 11:50:35 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VIoK013655; Thu, 31 Oct 2002 13:50:20 -0500 (EST) Message-Id: <200210311850.g9VIoK013655@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Brian Haberman'" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 09:33:04 PST.") <00dd01c28103$93376000$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 13:50:20 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes that appears to create a problem for multi-party apps, but the > problem of disconnectedness exists without a defined SL. Since SL makes > it clear that there are places where the network will be disconnected, > there should be a note to application developers stating what the > pitfalls are, along with any known work arounds. Having a clearly > defined prefix should make that task easier. having a clearly-defined prefix *does* make the need more apparent. but having the addresses be ambiguous makes the job of dealing with them considerably more difficult. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 10:53:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIr429003147; Thu, 31 Oct 2002 10:53:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VIr4bs003146; Thu, 31 Oct 2002 10:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VIr029003133 for ; Thu, 31 Oct 2002 10:53:00 -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 g9VIr8bB001243 for ; Thu, 31 Oct 2002 10:53:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07894 for ; Thu, 31 Oct 2002 10:53:03 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VIpB013723; Thu, 31 Oct 2002 13:51:11 -0500 (EST) Message-Id: <200210311851.g9VIpB013723@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 10:11:12 PST.") Date: Thu, 31 Oct 2002 13:51:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes it uses two-faced DNS. It works fine. not everyone uses Microsoft software, you know. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 11:00:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJ0Q29003375; Thu, 31 Oct 2002 11:00:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJ0Q9q003374; Thu, 31 Oct 2002 11:00:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJ0M29003367 for ; Thu, 31 Oct 2002 11:00:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VJ0UbB003928 for ; Thu, 31 Oct 2002 11:00:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09647 for ; Thu, 31 Oct 2002 12:00:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VJ05013766; Thu, 31 Oct 2002 14:00:05 -0500 (EST) Message-Id: <200210311900.g9VJ05013766@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 10:07:19 PST.") Date: Thu, 31 Oct 2002 14:00:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So we have a site with a globally-routable /48 prefix. Are you saying > that instead of using site-local addresses in addition to its global > addresses, the site could use a second /48 global prefix that is not > globally routable and is filtered at the site boundary? absolutely. > This would be silly. It would be just like site-locals except with a > non-standard prefix. no, the prefix should be standardized. > It would work worse than site-locals because > Default Address Selection wouldn't work properly Default address selection doesn't work properly anyway, partially because it favors SLs over globals, and partially because the idea that you can expect a default address selection rule to work in the absence of information about the app's requirements, and to do the right things with scoped addresses, is naive. > and because of Keith's > issue of distributed apps that do referrals - those apps wouldn't be > able to distinguish the two kinds of addresses to do the right thing. sure they would be able to distinguish them, because the prefix would be standardized. however "the right thing" is simply to favor routable globals over non-routable globals but to try all of them - that way, if two nodes don't manage to connect, it's either because the net is broken or the net is prohibiting the connection - either way it's beyond the the app's control. the app is able to do everything that can possibly be done and with almost zero additional complexity. compare this to the SL case where the app either has to a) artifically limit connectivity by filtering SLs when it's not sure that nodes could connect using them, OR b) include potentially SLs in referrals define an addressing scheme for all nodes used by the app whenever connecting to an SL address check to see whether you're really connecting to the node you think you're connecting to and perhaps implement routing across SL boundaries for the case where the customer demands that the app support it (which is quite often the case - people do expect apps to work across site boundaries) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 11:14:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJEd29003677; Thu, 31 Oct 2002 11:14:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJEdu9003676; Thu, 31 Oct 2002 11:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJEZ29003669 for ; Thu, 31 Oct 2002 11:14:36 -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 g9VJEibB009144 for ; Thu, 31 Oct 2002 11:14:44 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27504 for ; Thu, 31 Oct 2002 12:14:35 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 11:11:41 -0800 Reply-To: From: "Tony Hain" To: "'Jun-ichiro itojun Hagino'" , "'Richard Draves'" Cc: Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 11:11:33 -0800 Message-ID: <011801c28111$53f09ca0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20021031184639.CDB3A7B9@starfruit.itojun.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun wrote: > curious: do you run any router which participates to > multiple sites? Why would they? It is an address space that they can use for internal purposes. If they wanted to communicate to an external entity, they would either have to coordinate use of the SL space, or simply use globals. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:16:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJGp29003705; Thu, 31 Oct 2002 11:16:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJGptj003704; Thu, 31 Oct 2002 11:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJGk29003690 for ; Thu, 31 Oct 2002 11:16:46 -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 g9VJGsMq021240 for ; Thu, 31 Oct 2002 11:16:55 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03868 for ; Thu, 31 Oct 2002 12:16:39 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 11:16:45 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , "'Michel Py'" Cc: "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 11:16:37 -0800 Message-ID: <011e01c28112$08fe1960$237ba8c0@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.3416 In-Reply-To: <200210311848.g9VImO013637@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VJGk29003691 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > Problem is, nobody has bought this yet, because these addresses are > > PI, whatever you might call them, and will be misused and leaked to > > the defaultless table one day or the other, especially in > the lack of > > a multihoming solution. > > I don't buy it. If the standards say that ISPs in the public > Internet > are supposed to filter advertisements for global PI addresses, I'm > confident they will get filtered in the vast majority of cases. > > ... > > Of course if individual ISPs want to advertise routes to such > prefixes internally, perhaps because they're paid to do so, > that's their own > business. You contradict yourself. Michel points out that an unambiguous address space will be leaked, and you end up agreeing that the ISPs will do that when paid. The only way to prevent that case is for the ISP to have the technical barrier of ambiguity to push back on the business side of the house. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:16:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJGr29003708; Thu, 31 Oct 2002 11:16:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJGrHi003707; Thu, 31 Oct 2002 11:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJGl29003697 for ; Thu, 31 Oct 2002 11:16:47 -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 g9VJGuMq021246 for ; Thu, 31 Oct 2002 11:16:56 -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 MAA03958 for ; Thu, 31 Oct 2002 12:16:48 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Default site-local behavior for routers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2002 11:16:49 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3E6@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKA787Uoe9fDE0qRYamWfdrXaLrogAGO2DQAAIN4cA= From: "Michel Py" To: "Richard Draves" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VJGm29003698 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My two cents about two-faced DNS: In the v4 setups I have done, a one-faced DNS is enough if the DNS server is inside the NAT box, because the router that does NAT (at least the ones I have been using, Cisco) will decapsulate the DNS reply and replace the IP address with the public one. In a rather common Microsoft / Cisco / IPv4 / RFC1918 setup, the DNS servers often being domain controllers in the Active Directory and having RFC1918 addresses can indeed serve as SOAs and provide DNS services to the outside without any magic. All this to say that, as not-globally-routable, a DNS system that works both for the private and the public addresses is something that we already have for IPv4. If we want IPv6 to be adopted, we need to provide the same thing or better, which is valid for multihoming, DNS, and a bunch of other things. 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 Oct 31 11:20:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJKY29003824; Thu, 31 Oct 2002 11:20:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJKXSn003823; Thu, 31 Oct 2002 11:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJKT29003808 for ; Thu, 31 Oct 2002 11:20:29 -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 g9VJKbbB011297 for ; Thu, 31 Oct 2002 11:20:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06718 for ; Thu, 31 Oct 2002 12:20:27 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 11:20:33 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , "'Richard Draves'" Cc: "'Margaret Wasserman'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 11:20:25 -0800 Message-ID: <011f01c28112$90a545a0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200210311851.g9VIpB013723@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > Yes it uses two-faced DNS. It works fine. > > not everyone uses Microsoft software, you know. That was not a sales pitch from Rich, so don't turn it into one. The question Margaret asked was if anyone had an example of running code. A yes answer tends to deflate the argument that it can't be done. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:26:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJQh29003945; Thu, 31 Oct 2002 11:26:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJQg6u003944; Thu, 31 Oct 2002 11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJQd29003937 for ; Thu, 31 Oct 2002 11:26:39 -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 g9VJQmbB013781 for ; Thu, 31 Oct 2002 11:26:48 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02330 for ; Thu, 31 Oct 2002 11:26:42 -0800 (PST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24530 for ; Thu, 31 Oct 2002 14:26:41 -0500 (EST) Message-Id: <4.3.2.7.2.20021031142304.020d22d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Oct 2002 14:26:38 -0500 To: From: Ralph Droms Subject: RE: Default site-local behavior for routers In-Reply-To: <011801c28111$53f09ca0$237ba8c0@eagleswings> References: <20021031184639.CDB3A7B9@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perhaps Microsoft has a requirement for multiple, independent address spaces (there's nothing that requires Microsoft == one-site)? Or the Microsoft net is in some way adjacent to another network using SLs? Adjacent nets that both use SLs is an interesting (potentially problematic?) architecture - I would be interested in finding out about deployment experience with that case. - Ralph At 11:11 AM 10/31/2002 -0800, Tony Hain wrote: >itojun wrote: > > curious: do you run any router which participates to > > multiple sites? > >Why would they? It is an address space that they can use for internal >purposes. If they wanted to communicate to an external entity, they >would either have to coordinate use of the SL space, or simply use >globals. > >Tony > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:30:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJU729004022; Thu, 31 Oct 2002 11:30:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJU7Jg004021; Thu, 31 Oct 2002 11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJU329004014 for ; Thu, 31 Oct 2002 11:30: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 g9VJUCMq025865 for ; Thu, 31 Oct 2002 11:30:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21998 for ; Thu, 31 Oct 2002 11:30:06 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VJTl013940; Thu, 31 Oct 2002 14:29:47 -0500 (EST) Message-Id: <200210311929.g9VJTl013940@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Michel Py'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 11:16:37 PST.") <011e01c28112$08fe1960$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 14:29:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Of course if individual ISPs want to advertise routes to such > > prefixes internally, perhaps because they're paid to do so, > > that's their own > > business. > > You contradict yourself. Michel points out that an unambiguous address > space will be leaked, and you end up agreeing that the ISPs will do that > when paid. no. what an ISP advertises to itself and what it advertises (and accepts) across ISP boundaries are different things. > The only way to prevent that case is for the ISP to have the > technical barrier of ambiguity to push back on the business side of the > house. there are even better business reasons for filtering such advertisements unless the owner of that block of addresses is paying you specifically to route them within your network. that, and the threat of router overload for ISPs that don't filter such advertisements, should be sufficient. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:31:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJUx29004054; Thu, 31 Oct 2002 11:30:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJUxZN004053; Thu, 31 Oct 2002 11:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJUs29004043 for ; Thu, 31 Oct 2002 11:30:54 -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 g9VJV3bB015381 for ; Thu, 31 Oct 2002 11:31:03 -0800 (PST) Received: from starfruit.itojun.org (dhcp1252.nanog26.merit.net [192.35.165.252]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22592 for ; Thu, 31 Oct 2002 11:30:57 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 238F47B9; Fri, 1 Nov 2002 04:30:13 +0900 (JST) To: alh-ietf@tndh.net Cc: "'Richard Draves'" , ipng@sunroof.eng.sun.com In-reply-to: alh-ietf's message of Thu, 31 Oct 2002 11:11:33 PST. <011801c28111$53f09ca0$237ba8c0@eagleswings> 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: Default site-local behavior for routers From: Jun-ichiro itojun Hagino Date: Fri, 01 Nov 2002 04:30:13 +0900 Message-Id: <20021031193013.238F47B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> curious: do you run any router which participates to >> multiple sites? >Why would they? It is an address space that they can use for internal >purposes. If they wanted to communicate to an external entity, they >would either have to coordinate use of the SL space, or simply use >globals. depending on your definition of site border, Microsoft router can participate both Microsoft site as well as upstream-ISP site. see Miyakawa-san's DSL service plans - CPE participates to both ISP site as well as customer site. i still think it necessary to: - limit nodes from joining more than (including) 2 sites at the same time. - document site-border router's behavior in full 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 Thu Oct 31 11:32:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJWS29004105; Thu, 31 Oct 2002 11:32:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJWSib004104; Thu, 31 Oct 2002 11:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJWN29004096 for ; Thu, 31 Oct 2002 11:32:24 -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 g9VJWWbB016104 for ; Thu, 31 Oct 2002 11:32:32 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14700 for ; Thu, 31 Oct 2002 12:32:24 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VJVw013958; Thu, 31 Oct 2002 14:31:58 -0500 (EST) Message-Id: <200210311931.g9VJVw013958@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Richard Draves'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 11:20:25 PST.") <011f01c28112$90a545a0$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 14:31:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Yes it uses two-faced DNS. It works fine. > > > > not everyone uses Microsoft software, you know. > > That was not a sales pitch from Rich, so don't turn it into one. sorry, not how I read it at all - I read it as saying "it works for us". but since Microsoft mostly runs Microsoft software, the fact that SLs work within Microsoft isn't much of an indicator for sites that don't exclusively use Microsoft software. > The question Margaret asked was if anyone had an example of running code. > A yes answer tends to deflate the argument that it can't be done. nobody has claimed that a network using SLs can't be done - only that it's not a good idea. the fact that Microsoft has done something certainly doesn't demonstrate that it is a good idea. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:48:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJmx29004452; Thu, 31 Oct 2002 11:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJmxWI004451; Thu, 31 Oct 2002 11:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJmt29004444 for ; Thu, 31 Oct 2002 11:48:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VJn3Mq002106 for ; Thu, 31 Oct 2002 11:49:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAB04750 for ; Thu, 31 Oct 2002 11:48:58 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VJla014164; Thu, 31 Oct 2002 14:47:37 -0500 (EST) Message-Id: <200210311947.g9VJla014164@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Jun-ichiro itojun Hagino'" , "'Richard Draves'" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 11:11:33 PST.") <011801c28111$53f09ca0$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 14:47:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > curious: do you run any router which participates to > > multiple sites? > > Why would they? It is an address space that they can use for internal > purposes. If they wanted to communicate to an external entity, they > would either have to coordinate use of the SL space, or simply use > globals. well, if an issue with SLs is how they affect apps that talk across site boundaries, then it doesn't appear that they would have exercised that case unless they had multiple sites internal to their network. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 11:50:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJoc29004475; Thu, 31 Oct 2002 11:50:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VJocDC004474; Thu, 31 Oct 2002 11:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VJoX29004467 for ; Thu, 31 Oct 2002 11:50:33 -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 g9VJogMq002703 for ; Thu, 31 Oct 2002 11:50:42 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15475 for ; Thu, 31 Oct 2002 12:50:36 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VJoO014206; Thu, 31 Oct 2002 14:50:24 -0500 (EST) Message-Id: <200210311950.g9VJoO014206@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Richard Draves" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 11:16:49 PST.") <2B81403386729140A3A899A8B39B046405E3E6@server2000> Date: Thu, 31 Oct 2002 14:50:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My two cents about two-faced DNS: In the v4 setups I have done, a > one-faced DNS is enough if the DNS server is inside the NAT box, because > the router that does NAT (at least the ones I have been using, Cisco) > will decapsulate the DNS reply and replace the IP address with the > public one. and apps that communicate across the boundary and expect consistent results from DNS will break. > In a rather common Microsoft / Cisco / IPv4 / RFC1918 setup, since it violates RFC 1918, please don't call it an RFC 1918 setup. > All this to say that, as not-globally-routable, a DNS system that works > both for the private and the public addresses is something that we > already have for IPv4. "works" is a funny way to describe something that breaks apps and violates standards. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:00:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VK0629004686; Thu, 31 Oct 2002 12:00:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VK06h3004685; Thu, 31 Oct 2002 12:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VK0229004674 for ; Thu, 31 Oct 2002 12:00:02 -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 g9VK0BMq005630 for ; Thu, 31 Oct 2002 12:00:11 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02018 for ; Thu, 31 Oct 2002 12:59:59 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 11:59:33 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , "'Richard Draves'" Cc: "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 11:59:25 -0800 Message-ID: <012a01c28118$035649a0$237ba8c0@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.3416 In-Reply-To: <200210311900.g9VJ05013766@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VK0329004676 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > Default address selection doesn't work properly anyway, > partially because it favors SLs over globals, and partially > because the idea that you can > expect a default address selection rule to work in the > absence of information about the app's requirements, and to > do the right things with scoped > addresses, is naive. You appear to be skipping past the word 'default'. When an app has explicit requirements, it should not expect some default behavior underneath it to do the right thing. The point is that the majority of simple apps don't need to worry about this, because the stack can do the right thing for them. For the complex app, it will need to exercise its own address management rules in any case. > > > and because of Keith's > > issue of distributed apps that do referrals - those apps > wouldn't be > > able to distinguish the two kinds of addresses to do the > right thing. > > sure they would be able to distinguish them, because the prefix would > be standardized. however "the right thing" is simply to favor > routable globals over non-routable globals but to try all of > them - that way, if two nodes don't manage to connect, it's > either because > the net is broken or the net is prohibiting the connection - > either way it's beyond the the app's control. the app is > able to do everything that can possibly be done and with > almost zero additional complexity. The only difference between the non-routable globals and SL is the need for sites without routable global prefixes to coordinate the SL space when they connect. In the end, any prefix that is not in the global Internet routing table could be used as you describe, but disconnected sites want a prefix without paying a service provider for one, and connected sites don't want to pay for a second one and have to worry about it mistakenly being routed at some point. If we had a PI address mechansim, we could avoid the payment issue, but that would not remove the routability issue. The only way to technically reduce that threat is for the table to contain an ambiguous value. Something a provider might even be willing to intentionally black-hole as a value-added service. There are other fundemental business reasons we need a PI space. To help us take the fear out of routing table bloat, Michel and I have taken different approaches to define a PI space. If we get there, that space would make more sense for the multi-party app than SL, since it would otherwise would appear to be just another global prefix. > > compare this to the SL case where the app either has to > > a) artifically limit connectivity by filtering SLs when it's not sure > that nodes could connect using them, OR > > b) include potentially SLs in referrals > define an addressing scheme for all nodes used by the app > whenever connecting to an SL address check to see whether you're > really connecting to the node you think you're connecting to > and perhaps implement routing across SL boundaries for the case > where the customer demands that the app support it > (which is quite often the case - people do expect apps to work > across site boundaries) As I said, this is the basis of a BCP. I know you don't like the idea that it is the best we can do today in practice, but that is reality so let's move on. Rather than waste time trying to prevent a network manager from doing what he insists on doing, why don't we put the effort into getting a workable PI address space established so we can show an alternative with greater value. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:04:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VK4429004798; Thu, 31 Oct 2002 12:04:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VK44SO004797; Thu, 31 Oct 2002 12:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VK4129004790 for ; Thu, 31 Oct 2002 12:04: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 g9VK49bB027523 for ; Thu, 31 Oct 2002 12:04:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04943 for ; Thu, 31 Oct 2002 13:04:02 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 12:04:06 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Michel Py'" , "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 12:03:58 -0800 Message-ID: <012b01c28118$a6710c60$237ba8c0@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.3416 In-Reply-To: <200210311929.g9VJTl013940@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VK4129004791 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > no. what an ISP advertises to itself and what it advertises > (and accepts) across ISP boundaries are different things. You assume that an ISP is not paid enough to make sure the upstream is also paid to accept it. > > > The only way to prevent that case is for the ISP to have > the technical > > barrier of ambiguity to push back on the business side of the house. > > there are even better business reasons for filtering such > advertisements > unless the owner of that block of addresses is paying you > specifically > to route them within your network. that, and the threat of > router overload for ISPs that don't filter such > advertisements, should be sufficient. We have an existence proof in the current BGP table that it is not sufficient. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:16:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKGl29005050; Thu, 31 Oct 2002 12:16:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKGlo9005049; Thu, 31 Oct 2002 12:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKGe29005020 for ; Thu, 31 Oct 2002 12:16:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VKGmbB001797 for ; Thu, 31 Oct 2002 12:16:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12889 for ; Thu, 31 Oct 2002 13:16:08 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 12:16:11 -0800 Reply-To: From: "Tony Hain" To: "'Jun-ichiro itojun Hagino'" Cc: "'Richard Draves'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 12:16:03 -0800 Message-ID: <012c01c2811a$5795e7d0$237ba8c0@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.3416 In-Reply-To: <20021031193013.238F47B9@starfruit.itojun.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VKGe29005023 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun wrote: > ... > depending on your definition of site border, Microsoft > router can > participate both Microsoft site as well as upstream-ISP site. > > see Miyakawa-san's DSL service plans - CPE participates > to both ISP > site as well as customer site. Participate in both, but not route SL prefixes between them. This is easy since it can track which interface is appropriate for any given use. > > i still think it necessary to: > - limit nodes from joining more than (including) 2 > sites at the same > time. If it is not capable of tracking which interface is in which site, it should not be able to join more than one at a time. If it can, there is no reason to limit its ability to be connected to. > - document site-border router's behavior in full I agree that it should be documented. The conditions that need specific attention are; the case where there are multiple disconnected SL routing spaces, and the node just happens to be attached to more than one (multi-homed host model); the case where a site-border is also the transition between the IGP & EGP (well understood border model); the case where the site-border is expected to route between different SL address administrations (unless the interconnecting router is also a nat, this amounts to a normal IGP with one address domain under distributed management). Tony > > 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 Thu Oct 31 12:19:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKJF29005083; Thu, 31 Oct 2002 12:19:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKJF7X005082; Thu, 31 Oct 2002 12:19:15 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKJA29005075 for ; Thu, 31 Oct 2002 12:19:10 -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 g9VKJJMq011742 for ; Thu, 31 Oct 2002 12:19:19 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05108 for ; Thu, 31 Oct 2002 13:19:13 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VKJ1014376; Thu, 31 Oct 2002 15:19:01 -0500 (EST) Message-Id: <200210312019.g9VKJ1014376@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Richard Draves'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 11:59:25 PST.") <012a01c28118$035649a0$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 15:19:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > ... > > Default address selection doesn't work properly anyway,=20 > > partially because it favors SLs over globals, and partially=20 > > because the idea that you can=20 > > expect a default address selection rule to work in the=20 > > absence of information about the app's requirements, and to=20 > > do the right things with scoped=20 > > addresses, is naive. > > You appear to be skipping past the word 'default'. When an app has > explicit requirements, it should not expect some default behavior > underneath it to do the right thing. The point is that the majority of > simple apps don't need to worry about this, because the stack can do the > right thing for them. For the complex app, it will need to exercise its > own address management rules in any case. maybe we need to define what is a 'simple app' then for which the 'default' behavior suffices - because it seems to me that far too much faith is being placed in 'default address selection' to address the burden that is imposed by requiring hosts/apps to do address selection in the first place. in other words, just because a set of default rules might work for some apps is not a justification for requiring all apps to implement address selection code that often cannot work well. > The only difference between the non-routable globals and SL is the need > for sites without routable global prefixes to coordinate the SL space > when they connect. first, you make that sound easier than it really is; second, that's not the only difference. its not as easy as you make it out to be because there are industries that involve hundreds or thousands of suppliers (hundreds or thousands of separate sites) that want to make extensive use of private interconnects. it's easier to use non-routable globals than to make coordination of SLs scale to that degree. another difference is that non-routable globals are unambiguous, so that apps that operate across site boundaries aren't required to deal with ambiguous addresses. another difference is that with non-routable globals the app can allow the network to do all of the routing and enforce policy about who can connect to whom - with SLs the app will often have to do routing as site boundaries will not always coincide with boundaries of the application, and therefore any policy about who can talk to whom can only be implemented in the app. the ability of the network to provide security in depth is decreased with SLs. > In the end, any prefix that is not in the global > Internet routing table could be used as you describe, but disconnected > sites want a prefix without paying a service provider for one, and > connected sites don't want to pay for a second one and have to worry > about it mistakenly being routed at some point. I don't think paying for an address is a significant issue - the cost of getting an address (without connectivity) should be similar to that of getting a domain name - probably less, since trademark protection shouldn't be an issue for addresses. > If we had a PI address > mechansim, we could avoid the payment issue, but that would not remove > the routability issue. The only way to technically reduce that threat is > for the table to contain an ambiguous value. I've already explained why that 'threat' isn't a problem. > There are other fundemental business reasons we need a PI space. To help > us take the fear out of routing table bloat, Michel and I have taken > different approaches to define a PI space. If we get there, that space > would make more sense for the multi-party app than SL, since it would > otherwise would appear to be just another global prefix. we agree that a PI space is needed. now if we could just discourage use of SLs so that such apps would be able to run in most networks... > > compare this to the SL case where the app either has to=20 > >=20 > > a) artifically limit connectivity by filtering SLs when it's not sure > > that nodes could connect using them, OR=20 > >=20 > > b) include potentially SLs in referrals=20 > > define an addressing scheme for all nodes used by the app > > whenever connecting to an SL address check to see whether you're > > really connecting to the node you think you're connecting to > > and perhaps implement routing across SL boundaries for the case > > where the customer demands that the app support it > > (which is quite often the case - people do expect apps to work > > across site boundaries)=20 > > As I said, this is the basis of a BCP. I know you don't like the idea > that it is the best we can do today in practice, but that is reality so > let's move on. no, it's not even the best we can do in practice assuming we're stuck with SLs. as it is obvious that SLs present many difficulties on many levels of the stack, we really should declare consensus that they should be discouraged except in cases where we know they won't cause problems - like isolated networks - and move on. > Rather than waste time trying to prevent a network > manager from doing what he insists on doing, why don't we put the effort > into getting a workable PI address space established so we can show an > alternative with greater value. nobody is trying to 'prevent' the network manager from doing anything - but we would do well to provide such managers with the benefit of our understanding that SLs are not as good an idea as was originaly thought. and yes, let's get a workable PI space established. we seem to agree that this is a better alternative. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:24:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKOY29005190; Thu, 31 Oct 2002 12:24:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKOYTZ005189; Thu, 31 Oct 2002 12:24:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKOT29005179 for ; Thu, 31 Oct 2002 12:24:29 -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 g9VKOcMq013452 for ; Thu, 31 Oct 2002 12:24:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08714 for ; Thu, 31 Oct 2002 13:24:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VKOP014402; Thu, 31 Oct 2002 15:24:25 -0500 (EST) Message-Id: <200210312024.g9VKOP014402@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Michel Py'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 12:03:58 PST.") <012b01c28118$a6710c60$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 15:24:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > no. what an ISP advertises to itself and what it advertises > > (and accepts) across ISP boundaries are different things. > > You assume that an ISP is not paid enough to make sure the upstream is > also paid to accept it. If an ISP wants to pay each of its upstream ISPs to advertise those routes, and provide a single bill to its customers, it's free to do so. As routing table space becomes more precious, so will each ISP's cost to advertise a prefix. Provider-based routing will be cheaper because it needs to advertise fewer prefixes due to aggregation. > > there are even better business reasons for filtering such > > advertisements unless the owner of that block of addresses is paying you > > specifically to route them within your network. that, and the threat of > > router overload for ISPs that don't filter such > > advertisements, should be sufficient. > > We have an existence proof in the current BGP table that it is not > sufficient. as I already said, I don't think the current situation is a good predictor because of the IPv4 swamp, and because there is no clear distinction between provider-based and provider-independent addresses in IPv4. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:28:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKSa29005275; Thu, 31 Oct 2002 12:28:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKSabL005274; Thu, 31 Oct 2002 12:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKSX29005267 for ; Thu, 31 Oct 2002 12:28:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VKSgbB005833 for ; Thu, 31 Oct 2002 12:28:42 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25060 for ; Thu, 31 Oct 2002 13:28:36 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 12:26:03 -0800 Reply-To: From: "Tony Hain" To: "'Ralph Droms'" , Subject: RE: Default site-local behavior for routers Date: Thu, 31 Oct 2002 12:25:55 -0800 Message-ID: <012d01c2811b$b7930180$237ba8c0@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.3416 In-Reply-To: <4.3.2.7.2.20021031142304.020d22d0@funnel.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VKSX29005268 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph Droms wrote: > ... > Adjacent nets that both use SLs is an interesting (potentially > problematic?) architecture - I would be interested in finding > out about > deployment experience with that case. This is exactly the case that Keith is concerned about. There is no magic here, in this situation the address space needs to be coordinated, or a nat is required. Since we are all trying to avoid nat, the hammer approach is to simply ban SL. My argument is that it is more pragmatic to simply document the failure modes. If we can just do that, we will be able to put the effort into developing a PI approach with better support for the multi-party app. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:42:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKge29005425; Thu, 31 Oct 2002 12:42:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKgd53005424; Thu, 31 Oct 2002 12:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKga29005417 for ; Thu, 31 Oct 2002 12:42:36 -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 g9VKgfMq022120 for ; Thu, 31 Oct 2002 12:42:41 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09880 for ; Thu, 31 Oct 2002 12:42:35 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9VKg5BM071611; Fri, 1 Nov 2002 07:42:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210312042.g9VKg5BM071611@drugs.dv.isc.org> To: "Bound, Jim" Cc: "Rob Austein" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Limiting the Use of Site-Local In-reply-to: Your message of "Thu, 31 Oct 2002 00:25:27 CDT." <9C422444DE99BC46B3AD3C6EAFC9711B02BE97F1@tayexc13.americas.cpqcorp.net> Date: Fri, 01 Nov 2002 07:42:05 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark, > > > > Please think about this for a minute. It's bad enough for > > > applications that are driven by a human who can type or click or > > > whatever from a list of possible scopes, but what do you do for > > > programs like MTAs? If you're longing for a return to the days of > > > fee!fie%foe@fum email addresess (or even > > SRA@XX.LCS.MIT.EDU.#Chaos), > > > you're on the right road. > > > > No Rob. > > > > I'm talking about 1 name with multiple addresses being > > returned in multiple scopes. I'm taking about having > > getaddrinfo() then filter out the inappropriate addresses > > using local knowledge and setting sin6_scope_id. > > This deals with 99.9% of address lookup. > > We have not even agreed on what sin6_scope_ID is? It is also now > deprecated for futher study in this wg in the base API except for > link-local and in the IEEE. So how can you justify putting it in the > DNS except as research? Did not we all learn from AAAAv6? > > Can you define what you mean by "local knowledge" A mapping table between scope name (in the DNS) and sin6_scope_ID (being the 32 bit value that being used by the node to identify that site / link). > How does DNS know that scope applies to the node that did the > getaddrinfo if it don't know? Which all but a few implementations know > today and I have many questions for those that say they do. > > 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 > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:45:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKjw29005463; Thu, 31 Oct 2002 12:45:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKjwVq005462; Thu, 31 Oct 2002 12:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKjt29005455 for ; Thu, 31 Oct 2002 12:45: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 g9VKk3Mq023062 for ; Thu, 31 Oct 2002 12:46:03 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06700 for ; Thu, 31 Oct 2002 13:45:58 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01989 for ; Thu, 31 Oct 2002 15:45:57 -0500 (EST) Message-Id: <4.3.2.7.2.20021031153915.020900d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Oct 2002 15:45:54 -0500 To: From: Ralph Droms Subject: RE: Default site-local behavior for routers In-Reply-To: <012d01c2811b$b7930180$237ba8c0@eagleswings> References: <4.3.2.7.2.20021031142304.020d22d0@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 Tony, I don't know about any magic involved; I'm just interested in hearing about operational experience that would help us understand exactly what's involved in all of the possible cases. Also, perhaps it was good that I asked the question, because I'm not sure I understand part of your response. You wrote "the address space needs to be coordinated, or a nat is required." for a "PI approach with better support for the multi-party app." I must have missed this part of the thread in the flood of e-mail on the topic - are we looking for a way to support applications that span multiple sites that each use site-local addresses? - Ralph At 12:25 PM 10/31/2002 -0800, Tony Hain wrote: >Ralph Droms wrote: > > ... > > Adjacent nets that both use SLs is an interesting (potentially > > problematic?) architecture - I would be interested in finding > > out about > > deployment experience with that case. > >This is exactly the case that Keith is concerned about. There is no >magic here, in this situation the address space needs to be coordinated, >or a nat is required. Since we are all trying to avoid nat, the hammer >approach is to simply ban SL. My argument is that it is more pragmatic >to simply document the failure modes. If we can just do that, we will be >able to put the effort into developing a PI approach with better support >for the multi-party app. > >Tony > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:46:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkP29005492; Thu, 31 Oct 2002 12:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKkOFJ005489; Thu, 31 Oct 2002 12:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkE29005470 for ; Thu, 31 Oct 2002 12:46: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 g9VKkMbB010567 for ; Thu, 31 Oct 2002 12:46:22 -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 NAA22400 for ; Thu, 31 Oct 2002 13:46:17 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00458; Thu, 31 Oct 2002 12:46:04 -0800 (PST) Message-Id: <5.1.0.14.2.20021031154009.03015ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 15:41:09 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E3E5@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:17 PM 10/31/02, Michel Py wrote: >Margaret, > >[you have not adressed the security issues?] Which security issues? From what I can see, there are a number of people on this list who know a lot more than I do about security, and you are divided on the issue of whether or not IPv6 site-local unicast addresses have any security benefits at all... What would I have to add to that? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:46:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkP29005491; Thu, 31 Oct 2002 12:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKkOni005487; Thu, 31 Oct 2002 12:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkD29005465 for ; Thu, 31 Oct 2002 12:46: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 g9VKkMbB010566 for ; Thu, 31 Oct 2002 12:46:22 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24197 for ; Thu, 31 Oct 2002 12:46:16 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00425; Thu, 31 Oct 2002 12:46:00 -0800 (PST) Message-Id: <5.1.0.14.2.20021031153754.0292f0a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 15:38:39 -0500 To: From: Margaret Wasserman Subject: RE: Default site-local behavior for routers Cc: "'Brian Haberman'" , "'Mark Smith'" , In-Reply-To: <00c901c280ff$b8251910$237ba8c0@eagleswings> References: <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not true. There is no expectation that the _same_ IP address will point to two _different_ systems because it occurs on different sides of an IGP/EGP transition. Margaret At 12:05 PM 10/31/02, Tony Hain wrote: >Margaret Wasserman wrote: > > ... > > Are there any commercial routers today that include SBR support? > >By definition, every IGP/EGP transition is at least one example of site >border, so the answer to your question is yes. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 12:46:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkO29005490; Thu, 31 Oct 2002 12:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKkO7Q005488; Thu, 31 Oct 2002 12:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKkE29005473 for ; Thu, 31 Oct 2002 12:46: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 g9VKkNbB010570 for ; Thu, 31 Oct 2002 12:46:23 -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 NAA22405 for ; Thu, 31 Oct 2002 13:46:17 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00492; Thu, 31 Oct 2002 12:46:07 -0800 (PST) Message-Id: <5.1.0.14.2.20021031154444.03011080@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 15:44:57 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Default site-local behavior for routers Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 01:11 PM 10/31/02, Richard Draves wrote: > > Does anyone have an operational network that uses site-local > > addresses to provide private addressing within a globally > > connected network? Why did you choose to do this? What were > > your experiences? Please note that I am interested in > > deployed, operational networks, not theoretical deployments. > >Yes Microsoft operates such a network. Why? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 12:54:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKsZ29005747; Thu, 31 Oct 2002 12:54:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VKsZIk005746; Thu, 31 Oct 2002 12:54:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VKsU29005739 for ; Thu, 31 Oct 2002 12:54:30 -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 g9VKsdMq025577 for ; Thu, 31 Oct 2002 12:54:39 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12773 for ; Thu, 31 Oct 2002 13:54:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VKsH014562; Thu, 31 Oct 2002 15:54:17 -0500 (EST) Message-Id: <200210312054.g9VKsH014562@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Ralph Droms'" , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 12:25:55 PST.") <012d01c2811b$b7930180$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 15:54:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Adjacent nets that both use SLs is an interesting (potentially > > problematic?) architecture - I would be interested in finding > > out about > > deployment experience with that case. > > This is exactly the case that Keith is concerned about. There is no > magic here, in this situation the address space needs to be coordinated, > or a nat is required. Since we are all trying to avoid nat, the hammer > approach is to simply ban SL. My argument is that it is more pragmatic > to simply document the failure modes. I certainly think it's worthwhile to document the failure modes. I'm not at all sure it is more pragmatic to do "simply" that than to discourage SLs more forcefully - it's certainly easier to do the "simple" thing but I doubt that the result would be considered successful. I don't want to end up with lots of networks that use SLs and can't support apps because (as happened with NATs) network admins weren't sufficiently aware of just how much SLs break apps. (i.e. there's still a significant gap between documenting the failure modes and actually understanding how much this hurts - for the same reason that reading my "what nats break" web page doesn't tell you which of the apps that you want to run will not run.) as has been pointed out several times, SLs will be attractive to many network admins simply because they exist and they look like what many people are predisposed to think of as the "right" solution. so there's a bit of an uphill battle to discourage them, but I really think it's what we need to do. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 13:25:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VLPK29006158; Thu, 31 Oct 2002 13:25:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VLPJR4006157; Thu, 31 Oct 2002 13:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VLPF29006150 for ; Thu, 31 Oct 2002 13:25: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 g9VLPOMq004570 for ; Thu, 31 Oct 2002 13:25:24 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07306 for ; Thu, 31 Oct 2002 13:25:19 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VLOi014797; Thu, 31 Oct 2002 16:24:44 -0500 (EST) Message-Id: <200210312124.g9VLOi014797@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Thu, 31 Oct 2002 15:45:54 EST.") <4.3.2.7.2.20021031153915.020900d8@funnel.cisco.com> Date: Thu, 31 Oct 2002 16:24:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > are we looking for a way to > support applications that span multiple sites that each use site-local > addresses? the reality is that if SLs are widely used in v6 networks, apps will be expected to span sites using SLs, just as they are now expected to span between the public internet and sites using RFC 1918 addresses, and sometimes between multiple sites using RFC 1918 addresses. today that tends to require either that all nodes on private networks maintain an open connection to a point-of-contact in the public network, and/or that there be appliation-specific proxies at points where the various realms meet. and it often requires a fair amount of complexity in the app due to lack of a usable global address space and the need to do routing through such proxies. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 14:00:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VM0n29006366; Thu, 31 Oct 2002 14:00:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VM0nVk006365; Thu, 31 Oct 2002 14:00:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VM0j29006358 for ; Thu, 31 Oct 2002 14:00:46 -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 g9VM0sMq016326 for ; Thu, 31 Oct 2002 14:00:54 -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 OAA11904 for ; Thu, 31 Oct 2002 14:00:48 -0800 (PST) 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 g9VM18B22323 for ; Fri, 1 Nov 2002 00:01:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:00:47 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:46 +0200 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: Node requirements: RFC3041 - Privacy Extensions for Address Configuration in IPv6 Date: Fri, 1 Nov 2002 00:00:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Section 4.2.1 - draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIblu1uavIuUqVyR0uZA4aMzTOq0BldPDOA To: , Cc: X-OriginalArrivalTime: 31 Oct 2002 22:00:46.0525 (UTC) FILETIME=[F72AD6D0:01C28128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VM0k29006359 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Updating the node requirements and I came to this RFC. This RFC raised a lot of discussion during the Cellular Hosts draft - I wonder what the consensus is for the Node requirements. This could be useful for end-user hosts, but not at all for servers. I think for now, the safest thing would be to state this as a MAY, unless someone feels it should be stronger. If so, please submit text. 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 Thu Oct 31 14:07:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VM7729006444; Thu, 31 Oct 2002 14:07:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VM77vT006443; Thu, 31 Oct 2002 14:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VM7329006433 for ; Thu, 31 Oct 2002 14:07:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9VM7BMq018199 for ; Thu, 31 Oct 2002 14:07:11 -0800 (PST) Received: from starfruit.itojun.org (dhcp1252.nanog26.merit.net [192.35.165.252]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23903 for ; Thu, 31 Oct 2002 15:07:06 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C5DE57B9; Fri, 1 Nov 2002 07:06:21 +0900 (JST) To: alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com In-reply-to: alh-ietf's message of Thu, 31 Oct 2002 12:16:03 PST. <012c01c2811a$5795e7d0$237ba8c0@eagleswings> 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: Default site-local behavior for routers From: Jun-ichiro itojun Hagino Date: Fri, 01 Nov 2002 07:06:21 +0900 Message-Id: <20021031220621.C5DE57B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Participate in both, but not route SL prefixes between them. This is >easy since it can track which interface is appropriate for any given >use. you need to have separate routing table for those, or you need to do other tricks (like KAME's embedded link-local scope identifier). and routing protocol interaction is tricky. >> i still think it necessary to: >> - limit nodes from joining more than (including) 2 sites at the same >> time. >If it is not capable of tracking which interface is in which site, it >should not be able to join more than one at a time. If it can, there is >no reason to limit its ability to be connected to.=20 i'm proposing to limit it because it is (i believe) way too difficult to support routing protocol instances for multiple sites. for example, if you get a default route from three sites you are joined to, what are you going to do? or what if you get 2001:240::/32 from both sides, what are you going to do? 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 Thu Oct 31 14:10:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMAZ29006516; Thu, 31 Oct 2002 14:10:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMAY6O006515; Thu, 31 Oct 2002 14:10:34 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMAU29006499 for ; Thu, 31 Oct 2002 14:10:30 -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 g9VMAdMq019350 for ; Thu, 31 Oct 2002 14:10:39 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp3217.nanog26.merit.net [192.35.167.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26223 for ; Thu, 31 Oct 2002 15:10:34 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g9VMAnwc000987; Thu, 31 Oct 2002 23:10:50 +0100 (CET) Date: Thu, 31 Oct 2002 23:10:49 +0100 Subject: Re: Node Requirements Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Bound, Jim" , "Pekka Savola" , "Margaret Wasserman" , "Richard Draves" , ipng@sunroof.eng.sun.com To: Keith Moore From: Kurt Erik Lindqvist In-Reply-To: <200210281725.g9SHP7019914@astro.cs.utk.edu> Message-Id: <9CA9791E-ED1D-11D6-84E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > of course, just because there are implementations of SL and that > customers > have bought those implementations doesn't mean that widespread use of > SLs > is something that IETF should endorse. For what it's worth I agree. If we now specify a RFC1918 like structure for IPv6, we will be faced with people doing NAT like structures - for whatever reason, and a lot of what is considered the drive for IPv6 is gone. I have long argued that IPv6 only contribution to networking is a increase in addressing space - there is nothing I can do on IPv6 that I can't do on IPv4. A lot of people have then told me that IPv6 would help with peer-to-peer communications. With SL this is gone. Even if there might be reasons for a site to not need globally unique addresses, the problem is that at some point in the future that device will be on the net, and instead of renumbering, someone will do IPv6 NAT and the peer-to-peer/end-to-end models are gone. I agree that I don't think the installed base is a problem. If the small installations we have now is a problem, the problem of renumbering these sites with global addresses is not going to become smaller. History will repeat it self. - 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 Thu Oct 31 14:15:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMF429006599; Thu, 31 Oct 2002 14:15:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMF4JK006598; Thu, 31 Oct 2002 14:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMF129006591 for ; Thu, 31 Oct 2002 14:15:01 -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 g9VMF9Mq020569 for ; Thu, 31 Oct 2002 14:15:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28697 for ; Thu, 31 Oct 2002 15:15:04 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 14:15:06 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Richard Draves'" , "'Margaret Wasserman'" , Subject: RE: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 14:14:58 -0800 Message-ID: <013201c2812a$f3303eb0$237ba8c0@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.3416 In-Reply-To: <200210312019.g9VKJ1014376@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VMF129006592 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > maybe we need to define what is a 'simple app' then for which the > 'default' behavior suffices - because it seems to me that far > too much faith is being placed in 'default address selection' > to address the burden that is imposed by requiring hosts/apps > to do address > selection in the first place. > > in other words, just because a set of default rules might > work for some apps is not a justification for requiring all apps to > implement address selection code that often cannot work well. One address per interface doesn't solve all known problems either. > > > The only difference between the non-routable globals and SL is the > > need for sites without routable global prefixes to > coordinate the SL > > space when they connect. > > first, you make that sound easier than it really is; > second, that's not the only difference. > > its not as easy as you make it out to be because there are > industries that involve hundreds or thousands of suppliers > (hundreds or thousands of separate sites) that want to make > extensive use of private interconnects. it's easier to use > non-routable globals than to make coordination of SLs > scale to that degree. Careful, you are arguing that 38 bits is inadequate space for an industry specific registry... Also, this argument amounts to a claim that the industry can't manage an internal registry, but would be glad to impose its needs on the public registries. > > another difference is that non-routable globals are > unambiguous, so that apps that operate across site boundaries > aren't required to deal with > ambiguous addresses. Didn't you notice the phrase: 'coordinate the SL space when they connect'? If the space is coordinated, it is unambiguous. > another difference is that with > non-routable globals the app can allow the network to do all > of the routing and enforce policy > about who can connect to whom - with SLs the app will often > have to do routing as site boundaries will not always > coincide with boundaries of the application, and therefore > any policy about who can talk to whom can > only be implemented in the app. This is more an argument for PI than it is against SL. First, routing across a site boundary can't happen if the address space is ambiguous, because the routing protocols don't know how to deal with that. So you are either talking about nat, or a coordinated address space with a boundary router keeping the IGPs separated (a layer 3 area if you will). We won't waste time with the former, and the later does not exibit the application ambiguity problems you are worried about. > the ability of the network > to provide > security in depth is decreased with SLs. Let's stick to technical arguments... > ... > I've already explained why that 'threat' isn't a problem. Yet most enterprise network managers still believe it is. > ... > we agree that a PI space is needed. now if we could just > discourage use of SLs so that such apps would be able to run > in most networks... Shipping code will do more to change behavior than a few lines of text in an RFC. > ... > > As I said, this is the basis of a BCP. I know you don't > like the idea > > that it is the best we can do today in practice, but that > is reality > > so let's move on. > > no, it's not even the best we can do in practice assuming > we're stuck with SLs. > > as it is obvious that SLs present many difficulties on many > levels of the stack, we really should declare consensus that > they should be discouraged except in cases where we know they > won't cause problems - like isolated networks - and move on. This refuses to accept the fact that Rich says they are using them on a connected network without problems. > ... > nobody is trying to 'prevent' the network manager from doing > anything - but we would do well to provide such managers with > the benefit of our understanding that SLs are not as good an > idea as was originaly thought. > > and yes, let's get a workable PI space established. we seem to agree > that this is a better alternative. For the kinds of apps you are interested in, yes PI is where we need to be headed. I doubt we will ever convince people that it is better for some things that SL will get used for. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 14:36:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMav29006782; Thu, 31 Oct 2002 14:36:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMavUe006781; Thu, 31 Oct 2002 14:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMar29006774 for ; Thu, 31 Oct 2002 14:36:53 -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 g9VMb2bB014090 for ; Thu, 31 Oct 2002 14:37:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03042 for ; Thu, 31 Oct 2002 14:36:56 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VMaf015301; Thu, 31 Oct 2002 17:36:43 -0500 (EST) Message-Id: <200210312236.g9VMaf015301@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Richard Draves'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 14:14:58 PST.") <013201c2812a$f3303eb0$237ba8c0@eagleswings> Date: Thu, 31 Oct 2002 17:36:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > in other words, just because a set of default rules might > > work for some apps is not a justification for requiring all apps to > > implement address selection code that often cannot work well. > > One address per interface doesn't solve all known problems either. I didn't say it did, nor did I advocate that. (and there are so many things implied by "one address per interface" that it would take weeks to hammer out all of the details about which things you were trying to imply by that and which things you weren't. since it's not what either of us are advocating, let's just not go there) > > its not as easy as you make it out to be because there are > > industries that involve hundreds or thousands of suppliers > > (hundreds or thousands of separate sites) that want to make > > extensive use of private interconnects. it's easier to use > > non-routable globals than to make coordination of SLs > > scale to that degree. > > Careful, you are arguing that 38 bits is inadequate space for an > industry specific registry... Also, this argument amounts to a claim > that the industry can't manage an internal registry, but would be glad > to impose its needs on the public registries. no, I'm arguing that there aren't well-defined bounds on "the industry" (for any industry), so there are always potential collisions when you want to hook up some business that hasn't previously coordinated its use of SLs. and once you have the burden of getting an address block from such a registry you might as well use a global address space registry that prevents any potential collisions. > > another difference is that non-routable globals are > > unambiguous, so that apps that operate across site boundaries > > aren't required to deal with > > ambiguous addresses. > > Didn't you notice the phrase: 'coordinate the SL space when they > connect'? If the space is coordinated, it is unambiguous. you're assuming that IP connection boundaries are the same as app connection boundaries. they aren't. even if there are networks that coordinate use of SL space, there will still be apps that are expected to communicate across distinct 'sites'. (actually I prefer 'addressing realms' - 'sites' sounds too tied to geography. maybe we could call it realm-local addressing?) > > another difference is that with > > non-routable globals the app can allow the network to do all > > of the routing and enforce policy > > about who can connect to whom - with SLs the app will often > > have to do routing as site boundaries will not always > > coincide with boundaries of the application, and therefore > > any policy about who can talk to whom can > > only be implemented in the app. > > This is more an argument for PI than it is against SL. First, routing > across a site boundary can't happen if the address space is ambiguous, > because the routing protocols don't know how to deal with that. no, it just means that with SLs the apps have to do the routing between realms (and define their own addressing, and implement their own policy for where traffic can be routed) instead of having the network do that for them. > So you > are either talking about nat, or a coordinated address space with a > boundary router keeping the IGPs separated (a layer 3 area if you will). neither of the above. > > the ability of the network > > to provide > > security in depth is decreased with SLs. > > Let's stick to technical arguments... I just gave you one. > > ... > > I've already explained why that 'threat' isn't a problem. > > Yet most enterprise network managers still believe it is. beliefs and reality are different, it's true. but it's best to think of them separately. 'beliefs' can often be changed through education. > > ... > > we agree that a PI space is needed. now if we could just > > discourage use of SLs so that such apps would be able to run > > in most networks... > > Shipping code will do more to change behavior than a few lines of text > in an RFC. we could certainly ship code in both hosts and routers to discourage use of SLs, but somehow I don't think that's what you're suggesting... however host and router code implementors do read RFCs and sometimes they even do what they say. so having text in an RFC about how to deal with SLs really might have a useful effect. > > > As I said, this is the basis of a BCP. I know you don't > > like the idea > > > that it is the best we can do today in practice, but that > > is reality > > > so let's move on. > > > > no, it's not even the best we can do in practice assuming > > we're stuck with SLs. > > > > as it is obvious that SLs present many difficulties on many > > levels of the stack, we really should declare consensus that > > they should be discouraged except in cases where we know they > > won't cause problems - like isolated networks - and move on. > > This refuses to accept the fact that Rich says they are using them on a > connected network without problems. a network that only has one site and that primarily runs only one vendor's software doesn't exactly strike me as a good test case. > > ... > > nobody is trying to 'prevent' the network manager from doing > > anything - but we would do well to provide such managers with > > the benefit of our understanding that SLs are not as good an > > idea as was originaly thought. > > > > and yes, let's get a workable PI space established. we seem to agree > > that this is a better alternative. > > For the kinds of apps you are interested in, yes PI is where we need to > be headed. I doubt we will ever convince people that it is better for > some things that SL will get used for. well there are probably 'some' things for which SL really is a good idea. so far I haven't found many. and it would be really unfortunate if through misunderstanding SLs were given wider deployment than they deserve. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 14:45:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMjE29006895; Thu, 31 Oct 2002 14:45:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMjEYl006894; Thu, 31 Oct 2002 14:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMjB29006887 for ; Thu, 31 Oct 2002 14:45:11 -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 g9VMjKMq029867 for ; Thu, 31 Oct 2002 14:45:20 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24107 for ; Thu, 31 Oct 2002 14:45:13 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9VMj0BM072159; Fri, 1 Nov 2002 09:45:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210312245.g9VMj0BM072159@drugs.dv.isc.org> To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Default site-local behavior for routers In-reply-to: Your message of "Thu, 31 Oct 2002 10:11:12 -0800." Date: Fri, 01 Nov 2002 09:45:00 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Does anyone have an operational network that uses site-local > > addresses to provide private addressing within a globally > > connected network? Why did you choose to do this? What were > > your experiences? Please note that I am interested in > > deployed, operational networks, not theoretical deployments. > > Yes Microsoft operates such a network. > > > Have any network administrators installed a two-faced DNS > > that returns IPv6 site-local addresses within the site, but > > not externally? How did that work out? > > Yes it uses two-faced DNS. It works fine. > > Rich I suspect that you need to qualify that with "Provided there is only one site". Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 14:52:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMqW29006988; Thu, 31 Oct 2002 14:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMqWTa006987; Thu, 31 Oct 2002 14:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMqT29006977 for ; Thu, 31 Oct 2002 14:52:29 -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 g9VMqbMq001986 for ; Thu, 31 Oct 2002 14:52:37 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19813 for ; Thu, 31 Oct 2002 15:52:31 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VMqMKV017074; Thu, 31 Oct 2002 23:52:22 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 23:52:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C59@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Kurt Erik Lindqvist'" , Keith Moore Cc: "Bound, Jim" , Pekka Savola , Margaret Wasserman , Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Node Requirements Issue 3 Date: Thu, 31 Oct 2002 23:52:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > of course, just because there are implementations of SL and that > > customers > > have bought those implementations doesn't mean that > widespread use of > > SLs > > is something that IETF should endorse. > > For what it's worth I agree. If we now specify a RFC1918 > like structure > for IPv6, we will be faced with people doing NAT like > structures - for > whatever reason, and a lot of what is considered the drive > for IPv6 is > gone. => Why is it gone ? Not everyone wants NATs and for those who do, deprecating SL addresses will not help. It will just make their (Network admins) behaviour less predictable. > > I have long argued that IPv6 only contribution to networking is a > increase in addressing space - there is nothing I can do on > IPv6 that I > can't do on IPv4. => Yes there is. The address size itself allows to do things that you can't do with v4. Check out the SEND WG for example or MIPv6, or address autoconf.... A lot of people have then told me that IPv6 would > help with peer-to-peer communications. With SL this is > gone. => Obviously, if you choose to use SL for a disconnected network you're not interested in P2P on a global level. If you choose to use SL with globally routable addresses in the same network, you can get P2P. Even if > there might be reasons for a site to not need globally unique > addresses, the problem is that at some point in the future > that device > will be on the net, and instead of renumbering, someone > will do IPv6 > NAT and the peer-to-peer/end-to-end models are gone. I agree that I > don't think the installed base is a problem. If the small > installations > we have now is a problem, the problem of renumbering these > sites with > global addresses is not going to become smaller. > > History will repeat it self. => i don't know why some people try to resist existing facts. If you can't change it accept it and try to make the best out of it, i.e. write a BCP to tell people about the consequences of certain actions. Any attempt to change the world by deprecating SLs is an exercise in futility. Much better to educate people and hope that in time we will reduce the number of myths on the net. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 14:54:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMs929007017; Thu, 31 Oct 2002 14:54:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VMs8PY007016; Thu, 31 Oct 2002 14:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VMs529007008 for ; Thu, 31 Oct 2002 14:54:05 -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 g9VMsEMq002466 for ; Thu, 31 Oct 2002 14:54:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16727 for ; Thu, 31 Oct 2002 15:54:05 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9VMrwKV017251; Thu, 31 Oct 2002 23:53:58 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 23:53:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C5A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , Adam_Machalek@nmss.com, pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: RE: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 Date: Thu, 31 Oct 2002 23:53:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Updating the node requirements and I came to this RFC. > This RFC raised a lot > of discussion during the Cellular Hosts draft - I wonder > what the consensus > is for the Node requirements. This could be useful for > end-user hosts, => for _stationary_ end hosts. > but not at all for servers. > > I think for now, the safest thing would be to state this as > a MAY, unless > someone feels it should be stronger. If so, please submit text. => Yep. Hesham > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 15:20:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNK029007244; Thu, 31 Oct 2002 15:20:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VNK0ci007243; Thu, 31 Oct 2002 15:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNJu29007236 for ; Thu, 31 Oct 2002 15:19:56 -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 g9VNK5bB026736 for ; Thu, 31 Oct 2002 15:20:05 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19894 for ; Thu, 31 Oct 2002 16:19:59 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 31 Oct 2002 15:19:59 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Oct 2002 15:19:08 -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); Thu, 31 Oct 2002 15:19:58 -0800 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: Limiting the Use of Site-Local Date: Thu, 31 Oct 2002 15:19:57 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAYwj8Hrpm6yi+Q/uBZTWzwxgHBwAywfww From: "Richard Draves" To: "Keith Moore" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 31 Oct 2002 23:19:58.0110 (UTC) FILETIME=[07552BE0:01C28134] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g9VNJu29007237 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This would only cause trouble, I guess, if the customer's > system attributes some special security status to packets > that appear to come _from_ a site-local address, which would > be quite inadvisable. Hmm, perhaps there is some misunderstanding of how site-locals would be used for security, because the idea is in fact to give special security status to packets that come from a site-local address. Here's the model that I have in mind. First, the definition of a site has nothing to do with geography. It has to do with administrative & routing boundaries. The typical site is at least partially connected to the internet, so it has a global prefix. (Actually one or more global prefixes.) Plus it has the site-local prefix. The site uses a common subnet numbering plan across its prefixes, global and site-local. Applications use site-local addresses to ensure that communication is within the site. For example, one has a file server that is intended only for use within the site: the file server is restricted to only processing requests from site-local addresses. But the file server node also has a global address for other uses. In a more extreme example, one may have a private node that should only be accessible within the site, so the node has a site-local address but no global addresses. OK, so how does one implement this functionality without site-locals? The most obvious alternative is to do filtering or firewalling of the global prefix at nodes within the site. (Note - NOT filtering at the site boundary!) So the file server node is configured with a filter rule to block packets to the file service port with source addresses that don't match the site's global prefix. The private site-internal node is configured with a filter rule to block all packets with source addresses that don't match the site's global prefix. Etc. Now in previous email I pointed out the inherent "defense in depth" of the site-local prefix, because there will likely be multiple site-boundary routers between an attacker and the site, all of which would have to malfunction or be misconfigured to let the attacker's site-local packets into the site. In contrast, the alternative approach has no defense in depth. Any mistake in configuring the filter rules on a file server or private node lets the attacker through. And many more nodes have to be configured properly, because all the internal applications and private nodes have to be individually protected with filter rules, vs just configuring the site-boundary routers. If the site renumbers, all those filter rules have to updated properly. Now in recent email, if I understand correctly, Keith is proposing that non-routable global addresses replace site-locals in the above scenario. So the site would have its normal routable global prefix and also a non-routable global prefix. The non-routable global prefix would be standardized so that distributed applications could recognize it. This sounds exactly like site-locals with the 38 bits of zero replaced with a unique site identifier so that derived addresses are globally unique yet not globally routable (sites could make private peering arrangements to route them). (This is of course an idea that has been raised & rejected by the WG several times previously, but never mind that for now.) Keith, do I understand this right?? Thanks, 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 Thu Oct 31 15:30:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNUE29007426; Thu, 31 Oct 2002 15:30:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VNUE0F007425; Thu, 31 Oct 2002 15:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNUA29007415 for ; Thu, 31 Oct 2002 15:30:10 -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 g9VNUJbB029656 for ; Thu, 31 Oct 2002 15:30:19 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp3217.nanog26.merit.net [192.35.167.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18896 for ; Thu, 31 Oct 2002 15:30:13 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g9VNUXwc001003; Fri, 1 Nov 2002 00:30:33 +0100 (CET) Date: Fri, 1 Nov 2002 00:30:33 +0100 Subject: Re: Node Requirements Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ipng@sunroof.eng.sun.com To: "Hesham Soliman (EAB)" From: Kurt Erik Lindqvist In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C59@Esealnt861.al.sw.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> For what it's worth I agree. If we now specify a RFC1918 >> like structure >> for IPv6, we will be faced with people doing NAT like >> structures - for >> whatever reason, and a lot of what is considered the drive >> for IPv6 is >> gone. > > => Why is it gone ? Not everyone wants NATs and for those who > do, deprecating SL addresses will not help. It will just make > their (Network admins) behaviour less predictable. Maybe, but from a operator point of view, the advantage of being early on IPv6 is to enable your users to do peer-to-peer services. There are no new services I can launch just because I give out IPv6 address, on the contrary. There is most likely a higher cost involved. >> I have long argued that IPv6 only contribution to networking is a >> increase in addressing space - there is nothing I can do on >> IPv6 that I >> can't do on IPv4. > > => Yes there is. The address size itself allows to do things > that you can't do with v4. Check out the SEND WG for example > or MIPv6, or address autoconf.... This are all services / functions I could do in IPv4 as well. Perhaps not with the IPv4 address header though. > > A lot of people have then told me that IPv6 would >> help with peer-to-peer communications. With SL this is >> gone. > > => Obviously, if you choose to use SL for a disconnected > network you're not interested in P2P on a global level. At least not when I make that choice. That is how a lot of networks with RFC1918 space started out. > If you choose to use SL with globally routable addresses > in the same network, you can get P2P. If I have globally routeable addresses in the first place to identify my network devices, why would I want SL? If you give people a tool - they will use it, and eventually someone will hurt themselves with it. > > => i don't know why some people try to resist existing > facts. If you can't change it accept it and try to make I am not resisting facts. I am trying to argue that we should learn from mistakes. There are people who are using RFC1918 space today and are happy with it. There also a number of large organizations that have it and are very limited by it. I don't want us to give out tools with instructions for people with warnings on them. If they are dangerous we should not give them out at all. > the best out of it, i.e. write a BCP to tell people > about the consequences of certain actions. Any attempt > to change the world by deprecating SLs is an exercise > in futility. Much better to educate people and hope that > in time we will reduce the number of myths on the net. > I have still to see an argument as to what there is with SLs that I can't do with globaladdresses? - 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 Thu Oct 31 15:42:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNgH29007594; Thu, 31 Oct 2002 15:42:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9VNgHmW007593; Thu, 31 Oct 2002 15:42:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9VNgD29007586 for ; Thu, 31 Oct 2002 15:42:13 -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 g9VNgMMq017111 for ; Thu, 31 Oct 2002 15:42:22 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09257 for ; Thu, 31 Oct 2002 15:42:16 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9VNee015464; Thu, 31 Oct 2002 18:40:40 -0500 (EST) Message-Id: <200210312340.g9VNee015464@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Kurt Erik Lindqvist'" , Keith Moore , "Bound, Jim" , Pekka Savola , Margaret Wasserman , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 31 Oct 2002 23:52:21 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C59@Esealnt861.al.sw.ericsson.se> Date: Thu, 31 Oct 2002 18:40:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > For what it's worth I agree. If we now specify a RFC1918 > > like structure for IPv6, we will be faced with people doing NAT like > > structures - for whatever reason, and a lot of what is considered the drive > > for IPv6 is gone. > > => Why is it gone ? Not everyone wants NATs and for those who > do, deprecating SL addresses will not help. It will just make > their (Network admins) behaviour less predictable. it's not the case that NATs only affect networks that use them. widespread use of NATs makes the market for some kinds of apps so small, and the circumstances under which they can be used so difficult to recognize, that those apps essentially cannot be made commercially viable - at least not without adding a huge amount of overhead and complexity in the form of proxies and/or centralized servers, an doing addressing and routing internal to the app. similarly, it's not the case that SLs only affect networks that use them if SLs are widely used. > > A lot of people have then told me that IPv6 would > > help with peer-to-peer communications. With SL this is > > gone. > > => Obviously, if you choose to use SL for a disconnected > network you're not interested in P2P on a global level. > If you choose to use SL with globally routable addresses > in the same network, you can get P2P. presuming of course that the globally routable addresses are usable by any node that needs them. > > Even if there might be reasons for a site to not need globally unique > > addresses, the problem is that at some point in the future > > that device will be on the net, and instead of renumbering, someone > > will do IPv6 NAT and the peer-to-peer/end-to-end models are gone. > > I agree that I don't think the installed base is a problem. If the small > > installations we have now is a problem, the problem of renumbering these > > sites with global addresses is not going to become smaller. > > > > History will repeat it self. > > => i don't know why some people try to resist existing > facts. If you can't change it accept it and try to make > the best out of it, i.e. write a BCP to tell people > about the consequences of certain actions. Any attempt > to change the world by deprecating SLs is an exercise > in futility. Much better to educate people and hope that > in time we will reduce the number of myths on the net. SLs were not carved in stone by the hand of God and brought down from the mountain. They can indeed be deprecated, though I don't see much support for doing that. They can also be discouraged. A BCP that discourages uses of SLs except in certain narrow cases and explains why is probably more useful than a BCP that tries to explain exactly when SLs cause problems and when they don't. Of course, it's quite possible to have both. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 16:05:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA105w29007898; Thu, 31 Oct 2002 16:05:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA105wa7007897; Thu, 31 Oct 2002 16:05:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA105s29007890 for ; Thu, 31 Oct 2002 16:05:54 -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 gA1062Mq024265 for ; Thu, 31 Oct 2002 16:06:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21438 for ; Thu, 31 Oct 2002 16:05:57 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA105o015515; Thu, 31 Oct 2002 19:05:50 -0500 (EST) Message-Id: <200211010005.gA105o015515@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 15:19:57 PST.") Date: Thu, 31 Oct 2002 19:05:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This would only cause trouble, I guess, if the customer's > > system attributes some special security status to packets=20 > > that appear to come _from_ a site-local address, which would=20 > > be quite inadvisable. > > Hmm, perhaps there is some misunderstanding of how site-locals would be > used for security, because the idea is in fact to give special security > status to packets that come from a site-local address. I still think it's naive to expect that a single "site" can be a useful trust boundary in any significantly-sized network. > Applications use site-local addresses to ensure that communication is > within the site. For example, one has a file server that is intended > only for use within the site: the file server is restricted to only > processing requests from site-local addresses. But the file server node > also has a global address for other uses. In a more extreme example, one > may have a private node that should only be accessible within the site, > so the node has a site-local address but no global addresses. > > OK, so how does one implement this functionality without site-locals? > > The most obvious alternative is to do filtering or firewalling of the > global prefix at nodes within the site. (Note - NOT filtering at the > site boundary!) So the file server node is configured with a filter rule > to block packets to the file service port with source addresses that > don't match the site's global prefix. The private site-internal node is > configured with a filter rule to block all packets with source addresses > that don't match the site's global prefix. Etc. > > Now in previous email I pointed out the inherent "defense in depth" of > the site-local prefix, because there will likely be multiple > site-boundary routers between an attacker and the site, all of which > would have to malfunction or be misconfigured to let the attacker's > site-local packets into the site. > > In contrast, the alternative approach has no defense in depth. Any > mistake in configuring the filter rules on a file server or private node > lets the attacker through. no, it's pretty much the same problem. In one case you configure the server to not accept anything that's not a site-local. It's not inherently configured this way, because trust of SLs will not be appropriate for all servers. The server should not make any assumptions about the meaning of SLs out of the box - that's a matter for site configuration. In another case you configure the server to not accept anything that's not from one of a small number of prefixes. In either case the server can be misconfigured, denying authorized traffic or permitting unauthorized traffic. And either case has the potential for defense in depth because multiple routers (in addition to the host) can filter based on source address regardless of whether the prefix is an SL prefix or a global prefix. (and of course you do want to filter SLs at the site boundary - I assume you meant that the filtering isn't only at the site boundary) SLs do have two slight advantages here - 1. the filtering rules in your servers don't have to change when the site changes prefixes 2. more routers outside your site are likely to filter packets using SLs as source or destination addresses however I'd argue that the probability of both you and your ISP failing to filter traffic with source addresses containing your prefix should be very small, so statistically speaking #2 does not seem like a huge win. #1 does seem useful in the absence of a good way for servers to learn which global prefixes are currently trusted. but we need to solve the renumbering problem anyway. I don't claim that it can be solved by handwaving, but I do think that if we had a credible solution to the renumbering problem then #1 wouldn't be a significant argument in favor of SLs either. (and no I don't think that SLs make a significant dent in the renumbering problem) furthermore if you have multiple prefixes on a net, some of which are trusted and some which are not, then you have to configure each of those apps to tell them to use the trusted prefix. (telling them to use an SL address for the server will work with some apps - but not all of them - and if you use DNS names for the servers (which gives you some flexibility) then you get back to needing to figure out how to make SL work with DNS.) at any rate, the disadvantages associated with wide use of SLs still don't seem worth these slight advantages. > And many more nodes have to be configured > properly, because all the internal applications and private nodes have > to be individually protected with filter rules, vs just configuring the > site-boundary routers. you only get defense in depth if you have mulitiple layers of defense. claiming that SLs provide defense in depth on one hand and that you don't have to have multiple layers of defense on another hand doesn't seem consistent. > Now in recent email, if I understand correctly, Keith is proposing that > non-routable global addresses replace site-locals in the above scenario. > So the site would have its normal routable global prefix and also a > non-routable global prefix. The non-routable global prefix would be > standardized so that distributed applications could recognize it. a site with a routable prefix probably wouldn't need a non-routable prefix, and there are good reasons to not have more prefixes than needed. > This sounds exactly like site-locals with the 38 bits of zero replaced > with a unique site identifier so that derived addresses are globally > unique yet not globally routable (sites could make private peering > arrangements to route them). > > (This is of course an idea that has been raised & rejected by the WG > several times previously, but never mind that for now.) > > Keith, do I understand this right?? as a first approximation, it does sound right. (I'm not deterred by the previous rejection of the idea by the WG because the WG is now stating to understand both the harm done by SLs and the other reasons why PI addresses are needed ) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 16:09:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA109R29007949; Thu, 31 Oct 2002 16:09:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA109RG6007948; Thu, 31 Oct 2002 16:09:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA109O29007941 for ; Thu, 31 Oct 2002 16:09:24 -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 gA109WbB011170 for ; Thu, 31 Oct 2002 16:09:32 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28247 for ; Thu, 31 Oct 2002 17:09:25 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA109NKV023451; Fri, 1 Nov 2002 01:09:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 1 Nov 2002 01:09:23 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C5B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Kurt Erik Lindqvist'" , "Hesham Soliman (EAB)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Node Requirements Issue 3 Date: Fri, 1 Nov 2002 01:09:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Why is it gone ? Not everyone wants NATs and for those who > > do, deprecating SL addresses will not help. It will just make > > their (Network admins) behaviour less predictable. > > Maybe, but from a operator point of view, the advantage of > being early > on IPv6 is to enable your users to do peer-to-peer > services. There are > no new services I can launch just because I give out IPv6 > address, on > the contrary. There is most likely a higher cost involved. => I don't disagree with that, but I don't see the relevance to my statement. > > => Yes there is. The address size itself allows to do things > > that you can't do with v4. Check out the SEND WG for example > > or MIPv6, or address autoconf.... > > This are all services / functions I could do in IPv4 as > well. Perhaps > not with the IPv4 address header though. => I'll be very interested in seeing a proposal on secure ARP, MIPv4 RO or the final Zeroconf solution for IPv4 autoconf.... > > If you choose to use SL with globally routable addresses > > in the same network, you can get P2P. > > If I have globally routeable addresses in the first place > to identify > my network devices, why would I want SL? => If you don't want it, don't use it. No one is suggesting that every site must use them. If you give people > a tool - > they will use it, and eventually someone will hurt > themselves with it. => I don't think so. People will do what they want with whatever addresses they invent. Network admins are not kids. They are convinced that (in some cases) they need certain features. They will get there one way or another. You might disagree with their reasons or arguments, but there is no decision we take here that will change their minds immediately. > I am not resisting facts. I am trying to argue that we should learn > from mistakes. There are people who are using RFC1918 space > today and > are happy with it. There also a number of large > organizations that have > it and are very limited by it. I don't want us to give out > tools with > instructions for people with warnings on them. If they are > dangerous we > should not give them out at all. => Anything can be used in a dangerous way if people don't know what they're doing. So it is best to inform people, instead of giving them meaningless (to them) restrictions. > > I have still to see an argument as to what there is with SLs that I > can't do with globaladdresses? => Well, if after reading all the mails you still think so, don't expect one from me :) Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 16:16:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10Gi29008067; Thu, 31 Oct 2002 16:16:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA10GiBo008066; Thu, 31 Oct 2002 16:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10Gf29008059 for ; Thu, 31 Oct 2002 16:16:41 -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 gA10GnbB013016 for ; Thu, 31 Oct 2002 16:16:49 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23960 for ; Thu, 31 Oct 2002 17:16:43 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA10G7Q1011180; Fri, 1 Nov 2002 01:16:07 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 1 Nov 2002 01:16:07 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C5C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" , "Hesham Soliman (EAB)" Cc: "'Kurt Erik Lindqvist'" , "Bound, Jim" , Pekka Savola , Margaret Wasserman , Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: Node Requirements Issue 3 Date: Fri, 1 Nov 2002 01:16:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Why is it gone ? Not everyone wants NATs and for those who > > do, deprecating SL addresses will not help. It will just make > > their (Network admins) behaviour less predictable. > > it's not the case that NATs only affect networks that use them. > widespread use of NATs makes the market for some kinds of apps > so small, and the circumstances under which they can be used > so difficult to recognize, that those apps essentially cannot > be made commercially viable - at least not without adding > a huge amount of overhead and complexity in the form of > proxies and/or centralized servers, an doing addressing and > routing internal to the app. > > similarly, it's not the case that SLs only affect networks that > use them if SLs are widely used. => Yes, but my point is, this will happen independently of deprecating a bitstring. The /16 itself is meaningless; what we're arguing about is the use. So removing a /16 will not change anyone's mindset, it will just make things more unpredictable. > > => Obviously, if you choose to use SL for a disconnected > > network you're not interested in P2P on a global level. > > If you choose to use SL with globally routable addresses > > in the same network, you can get P2P. > > presuming of course that the globally routable addresses > are usable by any node that needs them. => Yes. > > => i don't know why some people try to resist existing > > facts. If you can't change it accept it and try to make > > the best out of it, i.e. write a BCP to tell people > > about the consequences of certain actions. Any attempt > > to change the world by deprecating SLs is an exercise > > in futility. Much better to educate people and hope that > > in time we will reduce the number of myths on the net. > > SLs were not carved in stone by the hand of God and brought > down from the mountain. > They can indeed be deprecated, though I don't see much > support for doing that. => Exactly, there is clearly no concensus on that. > They can also be discouraged. A BCP that discourages > uses of SLs except > in certain narrow cases and explains why is probably more > useful than a > BCP that tries to explain exactly when SLs cause problems > and when they don't. > Of course, it's quite possible to have both. => So let's have a shot at a BCP. It seems like a more productive step than the infinite loop that we're in right now. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 16:25:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10PA29008179; Thu, 31 Oct 2002 16:25:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA10P9hJ008178; Thu, 31 Oct 2002 16:25:09 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10P529008171 for ; Thu, 31 Oct 2002 16:25: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 gA10PEMq029876 for ; Thu, 31 Oct 2002 16:25:14 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28009 for ; Thu, 31 Oct 2002 17:25:08 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA10Nd015689; Thu, 31 Oct 2002 19:23:39 -0500 (EST) Message-Id: <200211010023.gA10Nd015689@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Keith Moore'" , "'Kurt Erik Lindqvist'" , "Bound, Jim" , Pekka Savola , Margaret Wasserman , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Fri, 01 Nov 2002 01:16:06 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C5C@Esealnt861.al.sw.ericsson.se> Date: Thu, 31 Oct 2002 19:23:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > similarly, it's not the case that SLs only affect networks that > > use them if SLs are widely used. > > => Yes, but my point is, this will happen independently > of deprecating a bitstring. The /16 itself is meaningless; > what we're arguing about is the use. So removing a /16 > will not change anyone's mindset, it will just make > things more unpredictable. well, there's no way to make a range of bit patterns cease to exist - that's even less feasible than willing the tide to go away. nor, as I've said several times, do I advocate re-allocating that range of bit patterns for any other purpose, or even declaring that they must not be used. it seems to me that the real question is whether we should continue to promote the idea that SLs are good for any kind of general-purpose use by applications (say for security), or whether we should discourage such use. if we can discourage use of SLs except in isolated networks or other rare corner cases, we'll avoid most of the potential harm that can come from them. > => Exactly, there is clearly no concensus on that. > > > They can also be discouraged. A BCP that discourages > > uses of SLs except in certain narrow cases and explains why is probably more > > useful than a BCP that tries to explain exactly when SLs cause problems > > and when they don't. Of course, it's quite possible to have both. > > => So let's have a shot at a BCP. It seems like > a more productive step than the infinite loop that > we're in right now. indeed. I actually think we might be getting somewhere. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 16:34:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10YI29008262; Thu, 31 Oct 2002 16:34:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA10YIj2008261; Thu, 31 Oct 2002 16:34:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10YE29008254 for ; Thu, 31 Oct 2002 16:34:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA10YNMq003054 for ; Thu, 31 Oct 2002 16:34:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02768 for ; Thu, 31 Oct 2002 17:34:18 -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 QAA02217; Thu, 31 Oct 2002 16:34:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA10YGI20500; Thu, 31 Oct 2002 16:34:16 -0800 X-mProtect: <200211010034> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaVWK04; Thu, 31 Oct 2002 16:34:13 PST Message-ID: <3DC1CCD9.90702@iprg.nokia.com> Date: Thu, 31 Oct 2002 16:37:45 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: Richard Draves , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local References: <200211010005.gA105o015515@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, I'm doing my best to follow this thread, but one item in your note to Rich Draves has me confused: Keith Moore wrote: > furthermore if you have multiple prefixes on a net, some of which > are trusted and some which are not, then you have to configure > each of those apps to tell them to use the trusted prefix. Can you say more about how this could occur in deployment scenarios? Prefixes come from router advertisements, stateful delegations (e.g., DHCPv6), or manual config - right? Are you saying that applications need to be configured in order to know which prefixes are legitimate and which are rogues? This sounds to me like either a site security issue or a requirement for an application-level prefix authentication mechanism - either way, it seems unrelated to the subject matter of this thread. 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 Thu Oct 31 16:41:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10fP29008381; Thu, 31 Oct 2002 16:41:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA10fOuW008380; Thu, 31 Oct 2002 16:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA10fL29008373 for ; Thu, 31 Oct 2002 16:41: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 gA10fUbB019671 for ; Thu, 31 Oct 2002 16:41:30 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03333 for ; Thu, 31 Oct 2002 17:41:24 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA21331; Thu, 31 Oct 2002 16:40:56 -0800 (PST) Message-Id: <5.1.0.14.2.20021031193507.0301bec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 19:38:46 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Node Requirements Issue 3 Cc: "Hesham Soliman (EAB)" , "'Kurt Erik Lindqvist'" , Keith Moore , "Bound, Jim" , Pekka Savola , Richard Draves , ipng@sunroof.eng.sun.com In-Reply-To: <200210312340.g9VNee015464@astro.cs.utk.edu> References: <(Your message of "Thu, 31 Oct 2002 23:52:21 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C59@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >A BCP that discourages uses of SLs except >in certain narrow cases and explains why is probably more useful than a >BCP that tries to explain exactly when SLs cause problems and when they don't. >Of course, it's quite possible to have both. I just happen to have a somewhat incomplete document lying around that I think could be an excellent start for this BCP. Unfortunately, we're past the -00 draft deadline, so I can't post it, but I will try to finish it up and post it after Atlanta. Who would like to help me fill in the missing pieces? I could particularly use some help documenting the issues that site-locals cause for: - Applications - Security Protocols (and security issues in general) - Transport Protocols (particularly the voice/session stuff) - DNS Keith, can I sign you up to help with applications? I think I have a good handle on the routing and network management issues, and some general issues. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 17:03:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA113r29008584; Thu, 31 Oct 2002 17:03:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA113rMw008583; Thu, 31 Oct 2002 17:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA113n29008576 for ; Thu, 31 Oct 2002 17:03:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA113wMq011932 for ; Thu, 31 Oct 2002 17:03:58 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20447 for ; Thu, 31 Oct 2002 17:03:52 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA113V015806; Thu, 31 Oct 2002 20:03:31 -0500 (EST) Message-Id: <200211010103.gA113V015806@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: Keith Moore , Richard Draves , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Thu, 31 Oct 2002 16:37:45 PST.") <3DC1CCD9.90702@iprg.nokia.com> Date: Thu, 31 Oct 2002 20:03:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm doing my best to follow this thread, but one item in your note > to Rich Draves has me confused: > > Keith Moore wrote: > > furthermore if you have multiple prefixes on a net, some of which > > are trusted and some which are not, then you have to configure > > each of those apps to tell them to use the trusted prefix. > > Can you say more about how this could occur in deployment > scenarios? Prefixes come from router advertisements, stateful > delegations (e.g., DHCPv6), or manual config - right? Are you > saying that applications need to be configured in order to know > which prefixes are legitimate and which are rogues? it is being claimed that 'servers' will know which sources of traffic are trustworthy based on source address. (yes, that's fairly dodgy , but a lot of sites do it for internal servers, so let's assume it's valid for the sake of argument) well, if you have multiple prefixes on the net, and some of those prefixes are trusted and some are not, then the apps (I don't like to say 'clients' because not all apps are client/server) have to know to use the trusted prefixes in order that the servers will trust them. this remains the case regardless of whether the trusted prefix is an SL prefix or not. but having SL prefixes assumed to be trustworthy by apps is one of the advantages being claimed for SL. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 17:05:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA115b29008606; Thu, 31 Oct 2002 17:05:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA115aAT008605; Thu, 31 Oct 2002 17:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA115W29008598 for ; Thu, 31 Oct 2002 17:05: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 gA115fbB026035 for ; Thu, 31 Oct 2002 17:05:41 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16606 for ; Thu, 31 Oct 2002 18:05:35 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA1140015828; Thu, 31 Oct 2002 20:04:00 -0500 (EST) Message-Id: <200211010104.gA1140015828@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , "Hesham Soliman (EAB)" , "'Kurt Erik Lindqvist'" , "Bound, Jim" , Pekka Savola , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-reply-to: (Your message of "Thu, 31 Oct 2002 19:38:46 EST.") <5.1.0.14.2.20021031193507.0301bec0@mail.windriver.com> Date: Thu, 31 Oct 2002 20:04:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith, can I sign you up to help with applications? absolutely. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 17:52:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA11qA29008873; Thu, 31 Oct 2002 17:52:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA11qAUK008872; Thu, 31 Oct 2002 17:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA11q729008865 for ; Thu, 31 Oct 2002 17:52:07 -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 gA11qFbB006537 for ; Thu, 31 Oct 2002 17:52:15 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp3217.nanog26.merit.net [192.35.167.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12404 for ; Thu, 31 Oct 2002 17:52:10 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA11qQwc001019; Fri, 1 Nov 2002 02:52:26 +0100 (CET) Date: Fri, 1 Nov 2002 02:52:25 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Keith Moore" , "Margaret Wasserman" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E3D5@server2000> Message-Id: <91F29568-ED3C-11D6-84E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On tisdag, okt 29, 2002, at 22:18 Europe/Stockholm, Michel Py wrote: > > Keith, what you are saying here is that the utility company is going to > have to use PA addresses, that it does not own, to configure tens of > thousands of devices on thousands of subnets, and be forced to renumber > if they want to switch ISPs, even though these devices have nothing to > do with the public Internet, just because you don't like SLs. ....and the day the utility company decides to outsource the monitoring they will have to renumber to global addresses anyway. - 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 Thu Oct 31 18:04:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA124S29008968; Thu, 31 Oct 2002 18:04:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA124SFU008967; Thu, 31 Oct 2002 18:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA124P29008960 for ; Thu, 31 Oct 2002 18:04:25 -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 gA124XMq025672 for ; Thu, 31 Oct 2002 18:04:33 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18185 for ; Thu, 31 Oct 2002 19:04:28 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2002 18:04:29 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3E7@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKBSVxxTKanGd/bSCShIXXGexBbAAAAR9xQ From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: "Keith Moore" , "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA124P29008961 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py >> Keith, what you are saying here is that the utility >> company is going to have to use PA addresses, that it >> does not own, to configure tens of thousands of devices >> on thousands of subnets, and be forced to renumber >> if they want to switch ISPs, even though these devices >> have nothing to do with the public Internet, just >> because you don't like SLs. > Kurt Erik Lindqvist wrote: > ....and the day the utility company decides to outsource the > monitoring they will have to renumber to global addresses > anyway. Total nonsense. 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 Oct 31 18:30:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA12UV29009083; Thu, 31 Oct 2002 18:30:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA12UUSM009082; Thu, 31 Oct 2002 18:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA12UR29009075 for ; Thu, 31 Oct 2002 18:30:27 -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 gA12UabB013817 for ; Thu, 31 Oct 2002 18:30:36 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp3217.nanog26.merit.net [192.35.167.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22624 for ; Thu, 31 Oct 2002 19:30:30 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA12Ujwc001090; Fri, 1 Nov 2002 03:30:45 +0100 (CET) Date: Fri, 1 Nov 2002 03:30:44 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ipng@sunroof.eng.sun.com To: Keith Moore From: Kurt Erik Lindqvist In-Reply-To: <200210292206.g9TM6D028661@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the same hardware that routes SLs within a site will be used > to block routing of SLs outside of a site - it's just a matter of > configuration as to whether they're on a site border or not. > in one case you tell the router to filter SLs, in another case > you tell it to filter all addresses with certain prefixes. To prove Keiths point, just look at how often any of the RFC1918 addresses occur in the global routing table. This is despite the fact that they are not supposed to be routed. 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 Thu Oct 31 19:00:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA130K29009460; Thu, 31 Oct 2002 19:00:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA130KX7009459; Thu, 31 Oct 2002 19:00:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA130H29009452 for ; Thu, 31 Oct 2002 19:00:17 -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 gA130PMq010814 for ; Thu, 31 Oct 2002 19:00:25 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09829 for ; Thu, 31 Oct 2002 20:00:20 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2002 19:00:23 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD29F@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKBUYAc9EKHlrCCTDKKn8SFbb8L/QAAReJg 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 gA130H29009453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Kurt Erik Lindqvist wrote: > To prove Keiths point, just look at how often any of > the RFC1918 addresses occur in the global routing > table. This is despite the fact that they are not > supposed to be routed. That's fine by me, anybody who tries to get to mine will get to the bozo that forgot to filter them instead. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 31 20:27:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA14R729009783; Thu, 31 Oct 2002 20:27:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA14R7eJ009782; Thu, 31 Oct 2002 20:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA14R429009775 for ; Thu, 31 Oct 2002 20:27: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 gA14RCbB003388 for ; Thu, 31 Oct 2002 20:27:12 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11707 for ; Thu, 31 Oct 2002 20:27:06 -0800 (PST) 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 gA14QfO18833 for ; Fri, 1 Nov 2002 06:26:41 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 06:27:04 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 06:27:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 06:27:01 +0200 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: Node Requirements Issue 3 Date: Fri, 1 Nov 2002 06:27:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node Requirements Issue 3 Thread-Index: AcKBQJDqI/3uud6gS0iKGxrleH5+6wAHjLQQ To: , Cc: , , , , , , X-OriginalArrivalTime: 01 Nov 2002 04:27:01.0443 (UTC) FILETIME=[EC7EB130:01C2815E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA14R429009776 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > - Transport Protocols (particularly the voice/session stuff) I think Randy Stewart has some draft out on IPv6 and SCTP, which talks about some scoping that SCTP needs, due to the support of multiple addresses. I think it is 'IPv6 and SCTP' - that might be a useful read for this topic. 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 Oct 31 22:56:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA16ul29010213; Thu, 31 Oct 2002 22:56:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA16ukWR010212; Thu, 31 Oct 2002 22:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA16ug29010205 for ; Thu, 31 Oct 2002 22:56:42 -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 gA16upbB021202 for ; Thu, 31 Oct 2002 22:56:51 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA29317 for ; Thu, 31 Oct 2002 23:56:36 -0700 (MST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gA16uTw5009383 for ; Thu, 31 Oct 2002 23:56:29 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id XAA16196 for ; Thu, 31 Oct 2002 23:56:28 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA16uQ7C002064 for ; Fri, 1 Nov 2002 17:56:26 +1100 (EST) Message-ID: <3DC22598.928A4E67@motorola.com> Date: Fri, 01 Nov 2002 17:56:24 +1100 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Why would I use a site-local address? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me weigh in late to offer an answer to the core question: Where would I use a site-local address? In a network with a statically allocated global IPv6 address, site-locals are indeed redundant. But: - IPv6 is built on the assumption that networks may renumber - Leaf networks currently are, and in future may well be, constructed with transient prefixes. - These leaf networks may not always have global connectivity. Consider a network using a dialup IPv4 connection to the router. While this connection is up, the network has a valid 2002:....:..../48 prefix. If the network goes down, or changes IPv4 address (and yes, this does happen), suddenly all our prefixes change. Prefix renumbering isn't too bad, since our IPv6 apps are supposed to be able to handle this. But while there is no prefix, there's no addresses. Connectivity over the site is lost pending availability of a new global prefix. Enter site locals. A solution is to allocate a site local prefix for the leaf network, as well as any global prefix/es that happen to exist. All these prefixes are given to the routers and hosts within the site. The border routers don't route site local addresses outside the site, and should also drop any packets with a site local source address. Sensible host source address selection rules are required. eg: prefer the source address that matches most closely with the destination address, and prefer globally scoped to site-local addresses (unless perhaps the target is also site local). Naming also can be site scoped. See: draft-williams-dnsext-private-namespace-01.txt for a site-scoped naming proposal. Under this model, there really is no need for multiple site-local scopes. The bits between /16 and /48 can be used to subdivide the site local space for manually partitioning, or else the full fec0::/48 space can be used and include whatever it can reach. As to router defaults, I'm inclined to suggest that backbone routers should perform site-local filtering unless explicitly configured to allow it between particular interfaces. Routers used within a site should freely route, but it's probably safer to require site-local forwarding to be off by default. People wanting more sophisticated configurations (with multiple different interfaces in multiple different sites) can manually configure how packets are to be routed. Site scoping boundaries can be bypassed through either tunnels or encapsulating addresses in higher level protocols. However, in this case things will simply fail to work, which is acceptable. With some effort, spoofing attacks are possible, but it is well known that hosts should not trust simple address based authentication for serious security. -- Andrew White Andrew.E.White@motorola.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------